The 3-Month Rule: A Practical Approach to Non-Scalable Coding Strategies
When it comes to building software, many of us have heard the wise words of Paul Graham: “Do things that don’t scale.” However, few seem to discuss how to practically apply this philosophy, especially in the realm of coding.
After spending the past eight months developing my AI podcast platform, I’ve established a straightforward framework to manage unscalable approaches. I call it the “3-Month Rule.” In this framework, each non-scalable solution has a lifespan of three months. At the end of that period, it must either demonstrate its value and evolve into a more robust solution or be discarded.
As engineers, we often aim to create scalable solutions from the outset. We gravitate towards established patterns, microservices, and distributed systems designed to handle large user bases. However, this mindset can be problematic, particularly in startup scenarios where such scalability may represent an unnecessary delay in progress.
My 3-Month Rule compels me to craft simple, straightforward, and often “inefficient” code that gets deployed and provides valuable insights into user needs. Here’s a look at some of my current infrastructure decisions that may seem unconventional but have proven to be quite effective.
Current Infrastructure Hacks: Smart Decisions in Disguise
1. Consolidated to One Virtual Machine
I run my entire platform—database, web server, background jobs, and Redis—on a single $40/month virtual machine, without any redundancy. Backups are done manually to my local machine.
Although this setup may seem reckless, it has allowed me to gain greater insights into my actual resource needs in just a couple of months. I discovered that my “AI-heavy” platform only requires about 4GB of RAM during peak usage. The complex Kubernetes infrastructure I nearly implemented would have been managing empty containers. During the few crashes I experienced, I gathered concrete data on the actual issues, none of which matched my initial assumptions.
2. Hardcoded Configurations
I utilize hardcoded configuration values for key parameters, such as pricing tiers and user limits. This approach enables me to quickly search my entire codebase for any configuration item and track changes via Git history with ease.
While developing a configuration service would involve significant engineering hours, I’ve made only a handful of changes in this area over three months. Considering the time saved, it’s a no-brainer.
3. Using SQLite in Production
I
