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,
