Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Solutions
In the startup world, many entrepreneurs frequently echo Paul Graham’s famous mantra: “Do things that don’t scale.” Yet, a common challenge emerges—how can we effectively implement this philosophy in our technical workflows, especially in coding?
In my journey of developing an AI podcast platform over the past eight months, I’ve adopted a straightforward framework known as the 3-Month Rule: any non-scalable method gets a trial period of three months. After this timeframe, it needs to either demonstrate its worth and be refined into a robust solution or be phased out entirely.
The crux of this approach lies in the distinction between the mindsets of conventional engineering and the agility required in a startup environment. While we are often trained to design scalable architectures, which can accommodate millions of users—think distributed systems and microservices—this mindset can lead to unnecessary complexity for early-stage products.
The 3-Month Rule in Action
In the context of my development experience, the focus on simplicity and speed over scaling can yield invaluable insights. Here are some of the non-scalable choices I’ve made, and how they have proven to be surprisingly astute:
1. Single VM Architecture
I host everything on a single $40/month virtual machine that encompasses the database, web server, background jobs, and even Redis—without any redundancy and with local manual backups.
Why is this workable? In just two months, I’ve garnered real insights into my resource usage—discovering my “AI-heavy” platform thrives on just 4GB of RAM. The elaborate Kubernetes setup I nearly implemented would have only managed overlooked empty containers.
When the system crashes—as it has twice thus far—I gather important data about what actually fails, which often surprises me.
2. Hardcoded Configuration Settings
I’ve chosen hardcoded constants for configurations, eliminating the need for separate config files or environment variables. Adjustments necessitate a redeployment, but that’s been minimal—averaging about three changes in three months.
The simplicity of this method allows for rapid searches across my codebase, and tweaking configurations remains an effortless task through Git. This approach has saved me countless engineering hours.
3. Using SQLite for Production
Yes, my multi-user web application operates on SQLite, and I must say, it performs magnificently with an entire database size of just 47MB and capable of handling
