The 3-Month Rule: A Pragmatic Approach to Non-Scalable Development
In the tech world, the advice from industry luminary Paul Graham resonates with many: “Do things that don’t scale.” Yet, implementing this philosophy in the realm of coding often leads to confusion or hesitation. Having spent eight months developing my AI podcast platform, I’ve devised a framework that keeps the focus on immediate learning and iteration: each experimental, unscalable solution is given a lifespan of three months. After this period, we either see substantial evidence of its value to justify further investment, or we retire it.
As software engineers, we are often conditioned to create scalable architectures from the outset—think design patterns, microservices, and distributed systems. While these concepts are impressive, they frequently represent the mindset of larger organizations. In a startup scenario, overly prioritizing scalability can lead to wasted resources as we chase problems that have yet to occur. My three-month rule encourages me to prioritize simplicity and deliver functional solutions quickly, ultimately leading to insights about user needs.
Current Infrastructure Hacks: Smart Simplicity
Here are several key practices that exemplify my approach and how they contribute to my project’s growth:
1. Single VM for Everything
I have consolidated my database, web server, background jobs, and caching—all on a single $40/month virtual machine. This setup lacks redundancy and relies on manual backups to my local system.
Why it Works: In just two months, I gained invaluable insight into actual resource usage that no capacity planning document could provide. My platform, despite being “AI-heavy,” only requires about 4GB of RAM during peak usage. A complex Kubernetes setup would have only served to manage idle containers.
When issues arise (and they did, on two occasions), I receive immediate feedback about where failures occur—often in unexpected areas.
2. Hardcoded Configurations
Price tiers, maximum users, and AI model definitions are hardcoded as constants within the code.
The Advantage: This approach allows me to quickly search and modify configuration values across the entire codebase. Each price adjustment is tracked in version control, ensuring each change is subject to review—even if I am my own reviewer. Setting up a dedicated configuration service would consume valuable development time; instead, I’ve made just three changes in three months, saving substantial engineering resources.
3. Using SQLite in Production
I operate a multi-user web application on a 47MB SQLite database,
