The 3-Month Rule: A Pragmatic Approach to Non-Scalable Development
In the world of tech startups, traditional wisdom often emphasizes the importance of scalability. Paul Graham famously advocates for “doing things that don’t scale,” yet implementing this advice, particularly in coding, isn’t frequently discussed. After eight months of building my AI podcast platform, I’ve found a simple yet effective approach: any non-scalable hack gets a dedicated lifespan of three months. At the end of that period, if it proves its worth, it’s built out; if not, it’s phased out.
As software engineers, we’re trained to construct “scalable” solutions from the onset. This entails creating intricate architectures like microservices and distributed systems aimed at supporting vast user bases. However, in the startup realm, investing energy into scalability can often be a form of expensive procrastination—focusing on future users and problems that may never materialize. By adhering to my 3-month rule, I’m encouraged to write straightforward, unrefined code that can be deployed immediately, revealing the genuine needs of my users.
My Current Infrastructure Hacks and Their Hidden Benefits
1. Single VM Architecture
I currently operate all components—database, web server, background jobs, and caching—on a single $40/month virtual machine (VM) without redundancy and manually back up data to my local drive. This might sound risky, but the insights I’ve gained in just two months have been invaluable. I’ve discovered my resource requirements firsthand, which was far more informative than any theoretical capacity planning report. The result? My “AI-intensive” platform peaks at a mere 4GB of RAM, rendering plans for a complex Kubernetes setup unnecessary.
2. Hardcoded Configuration
Instead of employing configuration files or environment variables, I utilize hardcoded constants throughout my codebase. Updating a configuration necessitates redeployment, but this method provides its own advantages. It allows for rapid searching across files, tracking changes in Git history, and conducting quick code reviews. Since I’ve adjusted configuration values only three times in three months, this approach saves weeks of engineering effort.
3. SQLite as a Production Solution
I’ve opted to run a SQLite database for my multi-user web application, which currently sits at a compact 47MB and easily accommodates 50 concurrent users. This decision has helped clarify my access patterns, revealing predominantly read operations. Had I initially chosen Postgres, I would have wasted time optimizing
