Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Development
In the realm of startups and emerging technologies, the wisdom of industry leaders often guides our strategies. Paul Graham famously encourages entrepreneurs to “do things that don’t scale.” However, translating that advice into practical coding strategies is seldom discussed. After spending eight months developing my AI podcast platform, I’ve crafted a straightforward approach: any unscalable solution is granted a lifespan of three months. After this period, it either demonstrates its worth and evolves into a fully-fledged feature, or it is discarded.
Rethinking the Way We Develop
As engineers, we are instinctively drawn to creating scalable solutions from the outset. The allure of design patterns, microservices, and distributed systems captures our imagination as we envision handling millions of users. However, this mindset often leads to complex architectures that can hinder progress in the startup environment.
In startups, striving for scalability too early can serve as a distraction from immediate needs. My 3-month rule encourages me to embrace simplicity and directly address what is necessary to launch. By doing so, I can better understand the true requirements of my users.
Current Infrastructure Hacks: How They Work to My Advantage
1. Consolidated Resources on a Single Virtual Machine
I run my entire operation—a database, web server, background jobs, and Redis—on a modest $40-a-month VM. While it may lack redundancy and relies on manual backups, this strategy has been instrumental in teaching me about my actual resource usage. From this setup, I’ve realized that my platform only peaks at 4GB of RAM. The more complicated Kubernetes framework I nearly implemented would have only led me to manage idle containers.
When crashes occur (and they have twice), I gain invaluable insights into real failure points—none of which were what I anticipated.
2. Hardcoded Configuration Values
My configuration strategy is simple: hardcoded constants across my codebase for tiered pricing, user limits, and model selection. This method may appear rudimentary, but it empowers me to quickly locate any configuration value using a simple grep search. Updates are tracked in git history, allowing me to maintain control over changes without extensive engineering time spent building a config service.
Over three months, I’ve modified these values only three times, saving countless hours of development in the process.
3. Utilizing SQLite in a Multi-User Environment
Surprisingly, I have opted to use SQLite for my
