Embracing the 3-Month Rule: A Strategic Framework for Agile Development
In the world of tech startups, the advice from renowned entrepreneur Paul Graham—”Do things that don’t scale”—often serves as a guiding principle. However, the challenge lies in translating this philosophy into actionable coding practices. After eight months of developing my AI podcast platform, I have crafted a straightforward approach: any temporary, non-scalable solution is given a lifespan of just three months to demonstrate its viability. If it proves beneficial, it gets the attention it deserves; if not, it’s time to let it go.
The typical mindset of software engineers is to pursue scalable solutions right from the outset, focusing on complex architectures designed to support millions of users. While this approach might suit established companies, it can lead startups down the path of expensive procrastination. By implementing my 3-month rule, I encourage myself to produce straightforward, albeit imperfect, code that actually makes it to production, helping me uncover the real needs of my users.
Key Technical Approaches and Their Value
1. Consolidated Infrastructure on One VM
I’ve opted to run my entire stack—including the database, web server, background jobs, and caching—on a single $40/month virtual machine. While this approach eliminates redundancy and relies on manual backups, it has provided invaluable insights. Within just a couple of months, I’ve gained a clearer understanding of my resource needs than I would have from extensive planning documents. For instance, it turns out my platform typically requires only 4GB of RAM. The complex Kubernetes setup I once considered would have been unnecessary overhead.
When outages occur, they provide real, actionable data on failure points, helping me learn where my assumptions were incorrect.
2. Simplified Hardcoded Configurations
With constants such as tiered pricing and user limits directly embedded in my code, I can make swift updates by redeploying. While storing configuration in separate files may be a best practice, the simplicity of my setup allows me to track each change easily through Git. This streamlined method means that minor alterations take mere minutes rather than consuming substantial engineering resources.
3. Using SQLite in a Production Environment
Despite SQLite traditionally being viewed as inadequate for multi-user applications, it has proven itself capable in my case. With a compact database size of 47MB and more than enough room to accommodate concurrent usage, I’ve discovered that the overwhelming majority of my operations are read-heavy. Had I opted for
