The Three-Month Rule: A Technical Approach to Unscalable Solutions

In the world of startups, conventional wisdom tells us to embrace the advice of Paul Graham: “Do things that don’t scale.” However, the challenge often lies in knowing how to effectively implement this philosophy, especially when it comes to coding.

Over the past eight months of developing my AI podcast platform, I have devised a straightforward framework that revolves around the concept of a three-month lifespan for any hack that cannot scale. At the end of this period, each solution must either demonstrate value and be refined further or be discarded entirely.

The reality for many engineers is the inclination to construct scalable solutions right from the outset, focusing on intricate design patterns, microservices, and elaborate architectures that are suited for handling millions of users. This methodology, while impressive, often aligns more with the mindset of large corporations than that of startups.

In a startup environment, prioritizing scalability can frequently lead to costly delays, as we may be preparing for user bases that do not yet exist while trying to solve problems that are not immediately relevant. My three-month rule encourages me to focus on building simple, direct, and sometimes “imperfect” code that can be deployed quickly. This approach has ultimately clarified my understanding of what my users truly need.

Current Infrastructure Strategies and Their Benefits

1. Consolidated VM Infrastructure
   Everything from the database to the web server and background processes operates on a single $40/month virtual machine. While this setup sacrifices redundancy and relies on manual backups, it has provided invaluable insights into my actual resource requirements. After two months, I’ve realized that my platform peaks at just 4GB of RAM. The sophisticated Kubernetes framework I almost implemented would have been unnecessarily complex and inefficient.

When system crashes occur (which they have, twice), I’m gaining real-time data about what genuinely fails—often revealing unexpected results.

1. Hardcoded Configuration Values
   Instead of employing configuration files or environment variables, I have hardcoded constants throughout my code. By doing this, I can swiftly search my codebase for specific values, and each alteration is meticulously tracked through git history. Over the past three months, I’ve only made three changes. The time saved by avoiding the creation of a separate configuration service has been immense.

2. Using SQLite in Production
   Surprisingly, I am utilizing SQLite for a multi-user application. With an entire database size of just 47MB, it handles up to 50