Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Solutions in Development
In the tech world, it’s a common refrain to “do things that don’t scale,” as famously articulated by Paul Graham. However, details on how to apply this principle in software engineering discussions often remain sparse. After dedicating eight months to developing my AI podcast platform, I’ve crafted a personal methodology: every non-scalable solution gets a lifespan of three months. At the end of this timeframe, if it hasn’t proven its worth, it’s time to let it go.
As engineers, we often aim to build scalable solutions from the outset, focusing on design patterns and distributed systems that serve vast user bases. Unfortunately, this mindset can lead to expensive delays at startups, where so many resources are allocated to potential user bases that may never materialize. By implementing my three-month rule, I prioritize writing straightforward code that is deployable, enabling me to learn directly from how my users interact with the platform.
Current Infrastructure Strategies: Rationalizing the Unconventional
1. Single VM Infrastructure
Right now, my database, web servers, Redis, and background jobs all run on a single virtual machine that costs $40 per month. While this might seem risky and lacking redundancy, it’s proven to be highly informative. In just two months, I’ve gathered more insights into my resource requirements than any theoretical capacity planning could provide. My “AI-heavy” platform has revealed a peak usage of just 4GB of RAM. Had I opted for a complex Kubernetes setup, I would have wasted time managing vacant resources instead of honing in on real user needs.
2. Hardcoded Configurations
Every configuration value is hardcoded—think constants throughout my files. This means changes require redeploying the code, which may sound cumbersome but offers a hidden advantage: I can quickly search my codebase for any configuration value. Tracking price changes is straightforward through Git history, and the cost of a few redeploys over three months pales in comparison to the week it would take to build a dedicated configuration service.
3. SQLite as a Production Database
I am currently utilizing SQLite for a multi-user application, handling a database size of just 47MB. Surprisingly, it caters to 50 concurrent users with ease. This setup has revealed my access patterns—95% reads and only 5% writes—perfect for SQLite. Had I started with a more robust system like
