Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Solutions in Tech Development
When it comes to startup culture, the mantra “do things that don’t scale” is often touted, especially by the likes of Paul Graham. However, the practical application of this advice in the realm of coding can often be overlooked. Over the past eight months while developing my AI podcast platform, I’ve crafted a straightforward framework to apply this principle: every unscalable approach is given a lifespan of just three months. After this period, it either proves its worth and gets refined, or it gets scrapped.
As engineers, we tend to gravitate towards crafting “scalable” solutions right from the outset. Concepts like design patterns, microservices, and distributed systems become our focus, emphasizing architecture capable of accommodating vast user bases. However, in the startup phase, this kind of thinking can often lead to costly delays, as we optimize for users that might not yet exist, tackling challenges that may never materialize. By adhering to my three-month rule, I prioritize writing straightforward, albeit imperfect, code that can be deployed quickly, allowing me to discern the actual needs of my users.
Current Infrastructure Strategies: A Look at My Intentional Hacks
1. Consolidation on a Single Virtual Machine
For just $40 a month, I operate my entire platform—database, web server, background jobs, and cache—on one single VM. While this may seem risky due to the lack of redundancy and reliance on manual backups, the reality is that I’ve gained invaluable insights into my resource needs in just two months. It turns out my AI-centric application peaks at just 4GB of RAM. Had I advanced straight to a complex Kubernetes deployment, I would have only been managing unused containers instead of focusing on what truly matters.
The occasional crashes (two so far) provide real-world data on failures. Interestingly, the issues that arise are seldom what I anticipated.
2. Simplistic Configuration Management
Rather than relying on configuration files or environment variables, I utilize hardcoded constants throughout my application—like pricing tiers and user limits. While this may seem rudimentary, it has significant advantages. Locating any configuration parameter takes mere seconds using a search command, and every change is documented in version control, providing a clear edit history.
Creating a dedicated configuration service might be tempting, but given that I’ve modified these values only three times in three months, the time investment required
