Embracing the 3-Month Rule: A Technical Framework for Non-Scalable Solutions

In the world of startups, a common mantra is Paul Graham’s insightful advice: “Do things that don’t scale.” Yet, when it comes to putting this principle into practice, especially in coding, guidance is often scarce. Over the past eight months of building my AI podcast platform, I have developed a straightforward approach that I call the “3-Month Rule.” This concept suggests that each unscalable solution is given a trial period of three months. At the end of this timeframe, it must either demonstrate its worth and be developed further or be phased out.

As engineers, our initial instinct is to design solutions with scalability in mind—think microservices, distributed systems, and intricate architecture capable of handling vast user numbers. However, this long-term perspective can be counterproductive in a startup environment, where investing time in scalable solutions may simply delay addressing immediate user needs. My 3-month framework encourages me to implement straightforward, even “messy,” code that allows me to deliver tangible results and gain invaluable user insights.

Current Infrastructure Hacks: Leveraging Simplicity for Learning

1. Consolidating on a Single VM

All critical components of my application—database, web server, background jobs—operate on a single $40 per month virtual machine. While this setup lacks redundancy, it has provided practical insights into my resource requirements. In just two months, I’ve learned that my platform’s demand peaks around 4GB of RAM—far removed from the complex Kubernetes architecture I initially considered. When failures occur, which has happened twice, I gain firsthand understanding of what actually goes wrong, often revealing surprises.

2. Hardcoded Configurations

Instead of utilizing configuration files or environment variables, I rely on hardcoded constants throughout my codebase, which might seem rudimentary but has its advantages. For example:
python
PRICE_TIER_1 = 9.99
MAX_USERS = 100
When adjustments are necessary, I can make changes quickly and efficiently. I’ve only updated these constants three times in three months, making the 15 minutes of redeployment far more efficient than the potential 40 hours of development for a configuration service.

3. Using SQLite in Production

While running SQLite for a web application may raise eyebrows, my database is only 47MB, easily supporting 50 concurrent users. This choice has illuminated my application’s