Embracing the 3-Month Rule: A Tactical Approach to Non-Scalable Solutions in Software Development
In the tech industry, particularly among startups, there’s a well-known piece of wisdom from Paul Graham: “Do things that don’t scale.” However, the challenge lies not just in grasping this concept but also in effectively applying it, especially when it comes to coding practices. After eight months of developing my AI podcast platform, I’ve established a straightforward framework: any non-scalable hack I implement is given a lifespan of three months. At the end of this period, I assess whether it has proven its value—either it evolves into a robust solution or it gets phased out.
The Cost of Over-Optimization
As engineers, we are often conditioned to focus on creating scalable solutions from the outset. We immerse ourselves in design patterns, microservices, and distributed systems, all crafted to handle potentially millions of users. However, this mindset can sometimes lead to premature optimization, particularly within the startup environment. Here, scalable infrastructure may simply postpone immediate issues while neglecting the need for quick, efficient feedback.
My three-month rule challenges me to create simple, straightforward, and sometimes “imperfect” code that allows me to rapidly learn what users genuinely need.
Current Infrastructure Hacks: A Practical Perspective
1. Unified VM Hosting
I’m currently operating my database, web server, background jobs, and Redis on a single virtual machine for just $40 per month. While it lacks redundancy and depends on manual backups, this approach has been surprisingly enlightening. Within two months, I gained insights about my actual resource usage that any capacity planning document could not provide. For instance, I discovered that my platform’s peak demand is a mere 4GB of RAM. The complex Kubernetes architecture I was contemplating would have been overkill.
2. Simplistic Configuration Management
My codebase features hardcoded configuration values such as pricing tiers and maximum user limits, distributed across various files. While this might seem inefficient, the reality is that it facilitates quick searches and changes. I’ve found it easier to track changes in git, and the time spent redeploying (a mere 15 minutes in three months) is drastically less than the weeks it would have taken to develop a sophisticated configuration management system.
3. SQLite as a Production Database
Surprisingly, I opted to use SQLite for my multi-user web app, which currently handles an impressive 50 concurrent users effortlessly.
