Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Solutions in Software Development
In the world of startups, the wisdom of Paul Graham’s advice — “do things that don’t scale” — often echoes in the minds of founders and engineers alike. However, the challenge lies in translating this concept into actionable strategies, particularly within the realm of coding. Over the past eight months while working on my AI podcast platform, I’ve developed a straightforward yet effective framework: each unscalable solution merits a trial period of three months. After this timeframe, it either proves its worth through tangible results or is set aside.
As engineers, we’re often conditioned to craft solutions designed for scale right from the outset. Whether it’s employing sophisticated design patterns or architecting microservices, the focus can easily shift to accommodating millions of users rather than addressing current needs. In a startup environment, however, optimizing for hypothetical users often leads to costly delays. The 3-month rule I’ve implemented pushes me to create simple, straightforward code that can ship quickly, providing real insights into user needs.
Current Infrastructure Strategies: Smart Hacks in Practice
1. Consolidated Infrastructure on One VM
I run my entire system — including the database, web server, background jobs, and caching — on a single $40 monthly virtual machine. This setup lacks redundancy and requires manual local backups, which might sound reckless but has proven invaluable. In just two months, I gained clarity on my actual resource usage, discovering that my platform’s peak demand only reaches 4GB of RAM. The complex Kubernetes deployment I nearly pursued would have merely involved managing idle containers. Each crash has provided critical data on failures, often in unexpected areas.
2. Hardcoded Configuration Across the Codebase
Instead of using external configuration files or environment variables, critical parameters such as pricing tiers and user limits are hardcoded directly into my application. While this may seem impractical, it allows for lightning-fast searches through my codebase to track values and deployment history in Git. Over three months, I’ve made only three configuration changes, averaging a mere quarter of an hour for redeployment compared to the substantial time it would have taken to set up a dedicated configuration service.
3. Utilizing SQLite in Production
Interestingly, I opted to deploy SQLite for a multi-user application, with a database size of only 47MB that gracefully manages up to 50 simultaneous users. This choice highlighted my access patterns, revealing
