Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Coding
In the world of startups and entrepreneurship, a well-known principle espoused by Paul Graham is the idea of “doing things that don’t scale.” While many applaud this approach in theory, implementing it in a coding environment can be quite a challenge. Having spent eight months developing my AI podcast platform, I’ve established a straightforward methodology: every unscalable tactic receives a lifespan of three months. After this period, it must either demonstrate its worth and be properly integrated or be discarded.
The startup Paradox: Focus on Learning, Not Just Scaling
As engineers, our training often emphasizes designing “scalable” solutions from the outset—think along the lines of intricate design patterns, microservices, and distributed systems. While these structures are impressive and essential for large enterprises, the reality for a startup is different. Focusing on scalable solutions can become an exercise in procrastination, optimizing for hypothetical users while neglecting the immediate needs of the current ones. My three-month rule promotes the development of straightforward, albeit imperfect, code that gets shipped and enables genuine user insights.
Current Infrastructure Strategies: Unconventional Yet Effective
1. Everything on One Virtual Machine
My entire infrastructure runs on a single $40/month virtual machine that houses my database, web server, background jobs, and Redis. While this setup lacks redundancy and relies on manual backups, it’s surprisingly informative. Within two months, I’ve learned far more about my actual resource demands than any planning document could have conveyed. For example, my “AI-heavy” platform only peaks at 4GB of RAM. The complex Kubernetes architecture I nearly implemented would have ended up managing idle containers, wasting resources.
2. Hardcoded Configurations
In my codebase, configuration values such as pricing tiers and user limits are hardcoded directly into the various files. No separate configuration files, no environment variables—just straightforward constants. While this may sound primitive, it has significant advantages. I can quickly track any changes or configurations through Git history and manage deployments with minimal effort. The time saved by avoiding the creation of a configuration management system is evident; I’ve only needed to change parameters three times in three months, saving countless engineering hours.
3. Utilizing SQLite for Production
Yes, I’ve opted to use SQLite for my multi-user web application, and it has proven effective. With a database size of just 47MB,
One Comment
This is a highly practical perspective that challenges the traditional emphasis on immediate scalability, especially for startups and early-stage projects. The 3-month rule offers a disciplined approach to experimenting with unscalable solutions, forcing teams to evaluate real-world utility versus hypothetical scalability early on. I appreciate how you highlight the value of learning from minimal infrastructure—like running everything on a single VM—and embracing simple, hardcoded configurations. These strategies effectively prioritize rapid iteration and user feedback, which are crucial in the early stages. Your approach underscores that sometimes, simplicity and agility outperform over-engineering. It’s a reminder that building intuition about actual resource demands and user needs can inform smarter, more sustainable scalability plans down the line. Thanks for sharing this insightful framework!