Embracing the 3-Month Rule: A Practical Framework for Non-Scalable Engineering

In the startup world, the mantra “Do things that don’t scale” — popularized by Paul Graham — is widely recognized, yet how to effectively implement this concept in software development often goes unaddressed. After dedicating the past eight months to creating an AI podcast platform, I’ve established a straightforward yet powerful framework that I call the “3-Month Rule.” This principle states that every unscalable approach is given a lifespan of precisely three months; at the end of this period, it must either prove its worth and transition into a proper solution or be discarded.

As engineers, we’re often conditioned to chase scalable solutions from the outset. Designing intricate architectures like microservices or distributed systems tends to dominate our thought process, as we imagine accommodating millions of users down the line. However, in the startup arena, this quest for scalability can become an exercise in procrastination, as it often distracts us from addressing the immediate needs of current users.

A Framework for Learning Through Experimentation

The 3-Month Rule compels me to write simple and quick code that can be deployed rapidly, allowing me to gain insights into user needs and behaviors. Here are some practical “hacks” that exemplify this approach and demonstrate their underlying intelligence:

1. Single Virtual Machine Infrastructure

All components of my platform — including the web server, database, and background jobs — are hosted on one $40/month virtual machine. This may seem reckless without redundancy or automatic backups, but I’ve gained invaluable insights about resource usage within just two months. For instance, I learned that my workload peaked at a mere 4GB of RAM, demonstrating that the complex Kubernetes architecture I nearly implemented would have managed resources I didn’t even need.

When issues arise (as they inevitably do), I receive real-time data about the actual points of failure, which often surprise me.

2. Hardcoded Configuration Values

My configuration setup is straightforward: constants like PRICE_TIER_1, MAX_USERS, and others are hardcoded in the codebase. Any changes necessitate a redeploy, but the efficiency gain is palpable. By avoiding external configuration files or environment variables, I can quickly search and track modifications while maintaining an accurate history in version control. In three months, I’ve made only three adjustments, saving a considerable amount of engineering time.

3. Using SQLite for Production

Believe it or not