Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions

In the tech landscape, Paul Graham’s famous advice to “do things that don’t scale” resonates with many founders and engineers. However, when it comes to effectively applying this concept within software development, practical strategies often seem elusive. After spending the last eight months building my AI podcast platform, I’ve adopted a straightforward framework: each unscalable tactic is given a lifespan of three months. If it proves its worth, it evolves into a refined solution; if it doesn’t, it gets discarded.

Engineers are typically trained to prioritize scalable solutions right from the outset—crafting intricate architectures, utilizing microservices, and designing systems robust enough to manage millions of users. However, this mindset can be detrimental for startups. In our early stages, crafting scalable code can often lead to costly delays, focusing on hypothetical users and problems that may never materialize. My three-month rule pushes me to embrace simplicity and focus on producing “imperfect” code that provides real insight into users’ needs.

Current Infrastructure Hacks: Insights from Simplified Solutions

1. Consolidated Operations on a Single VM

Everything—database, web server, background jobs, and caching—runs on a single $40/month virtual machine with no redundancy and manual backups to my local system. This setup might seem reckless, but it’s revealing. Within two months, I gained a clearer understanding of my actual resource requirements, discovering my platform’s peak usage is only 4GB of RAM. The complex Kubernetes arrangement I almost implemented would have simply led to managing idle containers. Each time the system crashes, which has happened twice, I receive invaluable data on what fails—often surprising me.

2. Hardcoded Configurations

Every single configuration value, from pricing tiers to user limits, is hardcoded within my codebase. This might raise eyebrows, but it comes with hidden advantages. I can easily search for any configuration value across files, and every change is meticulously logged in the git history. Instead of spending a week building a configuration service, I’ve redeployed three times in three months, which took only 15 minutes each time compared to the potential 40 hours for a more sophisticated solution.

3. Utilizing SQLite for Production

I currently use SQLite for a multi-user application, with a total database size of just 47MB. Remarkably, it comfortably manages 50 concurrent users. My exploration revealed that