Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions
In the realm of startups, the oft-cited wisdom of Paul Graham, “Do things that don’t scale,” frequently resonates. However, the practical application of this advice in the context of coding can be less discussed. After eight months of developing my AI-focused podcast platform, I’ve devised a straightforward framework: every non-scalable solution gets a lifespan of three months. If a particular solution does not demonstrate its worth by then, it is effectively retired.
The challenge many developers face is that we are conditioned to prioritize scalable solutions from the outset. Concepts like design patterns, microservices, and intricate distributed systems are alluring. They cater to the needs of large organizations managing vast user bases. However, in a startup environment, chasing scalability too early often leads to costly delays — optimizing for hypothetical users instead of current needs. My 3-month rule encourages me to produce straightforward, albeit imperfect, code that is functional and provides insights into actual user interactions.
My Current Infrastructure Strategies and Their Value:
1. Consolidated Setup on a Single Virtual Machine
I operate my database, web server, background tasks, and caching on a single $40/month virtual machine (VM) with no redundancy and manual backups.
This setup may seem simplistic, but here’s its clever side: in just two months, I’ve gained better insight into my resource requirements than any exhaustive capacity report could provide. My platform, despite being labeled “AI-heavy,” peaks at 4GB RAM. The intricate Kubernetes infrastructure I almost implemented would have merely juggled idle containers.
Whenever the system crashes (which happened twice), I gather real-time data on failures, which often reveal insights I hadn’t anticipated.
2. Hardcoded Configuration for Simplicity
Instead of employing configuration files or environment variables, I utilize hardcoded constants across my codebase. For example:
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
While this may seem counterintuitive, it provides an unexpected advantage: I can quickly search for any configuration value throughout my code. Each parameter change is documented in my git history, and even though I review my own pull requests, they still receive due diligence.
Crafting a separate configuration service would have consumed a week’s worth of time.
One Comment
Thank you for sharing such a pragmatic and insightful approach to early-stage development. The 3-month rule is a valuable framework, especially in lean startup environments where resource allocation and timely learning are critical. I appreciate how you emphasize quick, functional solutions that allow for real user feedback rather than over-investing in complex, scalable architectures too early.
Your example of consolidating on a single VM and using hardcoded configurations highlights an important point: simplicity often accelerates learning. It allows developers to iterate rapidly, identify bottlenecks, and understand actual needs before committing to more sophisticated systems.
This approach aligns well with the idea of “fail fast, learn faster,” ensuring that efforts are guided by real-world data rather than assumptions. It’s a reminder that scalability can be engineered later, once validated, rather than hindered by premature optimization.
Have you found particular signals or metrics during this three-month period that most reliably indicate when it’s time to shift towards more scalable solutions?