The 3-Month Rule: A Practical Approach to Non-Scalable Solutions in Software Development
In the tech world, the advice from Paul Graham to “do things that don’t scale” often inspires startup founders and developers alike. However, the practical implementation of this philosophy in coding practices is rarely discussed.
Having spent the past eight months developing my AI podcast platform, I’ve crafted a straightforward framework: each non-scalable hack is given a lifespan of three months. At the end of this period, if it has demonstrated its value, it will be developed into a more robust solution; otherwise, it will be discarded.
As engineers, we are often conditioned to focus on building scalable solutions from the outset. We immerse ourselves in intricate design patterns, microservices architectures, and distributed systems, all tailored to support millions of users. However, this kind of thinking can be counterproductive for startups, leading us to optimize for growth that may never materialize. By adhering to my three-month rule, I challenge myself to write straightforward and sometimes “flawed” code that can be deployed quickly, enabling me to better understand my users’ true needs.
Current Infrastructure Hacks that Prove Their Worth
1. Consolidating Everything on One Virtual Machine
My setup includes a database, web server, background jobs, and Redis, all hosted on a single $40/month virtual machine. This approach, devoid of redundancy and relying on manual backups, may seem backward, but it has provided invaluable insights into my actual resource requirements. In just two months, I’ve learned that my “AI-heavy” application peaks at 4GB RAM. The complex Kubernetes environment I nearly implemented would have resulted in managing idle containers, leading to wasted effort.
Moreover, each crash has yielded real-time data regarding the causes, often diverging from my initial assumptions.
2. Simplified Configuration Management
Instead of extensive configuration files or environment variables, I utilize hardcoded constants throughout my project. Whether it’s setting price tiers or defining the maximum number of users, changes require a redeployment, but I can quickly search through my codebase for any configuration value. This methodology has streamlined my process: significant updates have been infrequent, with just three changes in three months, resulting in 15 minutes of redeployment compared to the 40 hours it would have taken to build a configuration service.
3. Leveraging SQLite in Production
Currently, my production environment runs on SQLite, despite being a multi-user web app
