The 3-Month Rule: A Practical Approach to Non-Scalable Solutions in Software Development
In the tech world, particularly among startups, there’s often a mantra that resonates with entrepreneurs and engineers alike: “Do things that don’t scale.” While this principle, famously promoted by Paul Graham, is widely acknowledged, the real challenge lies in how to effectively implement it in the realm of coding.
After eight months of developing my AI podcast platform, I’ve devised a straightforward framework: each unscalable hack is given a lifespan of three months. At the end of this period, the approach must either demonstrate its value and transition into a more robust solution or be discarded.
As software engineers, we’re conditioned to prioritize scalability, envisioning grand architectures capable of serving millions of users. This is the mindset suited for large enterprises, but in the startup environment, such lofty aspirations can lead to costly delays. Often, what we think is optimizing for future users translates to unnecessary complexity. My 3-Month Rule encourages me to embrace simplicity and allows me to write straightforward, albeit imperfect, code. This way, I can quickly learn what my users genuinely need.
Current Strategies and Their Underrated Benefits
1. Unified VM Infrastructure
All my services—including the database, web server, background jobs, and Redis—operate from a single, modestly-priced virtual machine. This setup has no redundancy, and I manage backups manually.
Why is this a wise choice? It has provided invaluable insights into my actual resource needs. I’ve identified that my “AI-heavy” application requires only about 4GB of RAM at peak usage. The complex Kubernetes environment I considered wouldn’t have been able to justify its complexity and would have resulted in managing idle containers. When the system does crash (which has happened a couple of times), I can gather concrete data on the failure points, which often surprises me.
2. Simplistic Configuration Management
My configuration settings—like pricing tiers and maximum user counts—are hardcoded as constants in my code. There’s no use of configuration files or environment variables, meaning any changes necessitate a redeployment.
The benefit of this approach is evident: I can quickly search my entire codebase for any configuration values. Each price adjustment is documented in git history, and even though I evaluate my own pull requests, these reviews ensure accountability. Building a dedicated configuration service would consume a week of development time, but I’ve only needed to make changes three times in three months.
