Embracing the 3-Month Rule: A Practical Approach to Building Unscalable Solutions

In the ever-evolving landscape of software development, the advice from Paul Graham—”Do things that don’t scale”—is often echoed but seldom acted upon, especially when it comes to coding. Having spent the last eight months developing an AI podcast platform, I’ve established a straightforward methodology that I like to call the 3-Month Rule. This framework suggests that any unscalable hack I implement is given a lifespan of three months; after this period, it either demonstrates its worth and gets the necessary infrastructure support, or it is discarded.

The Challenge of Scalability

As software engineers, we are conditioned to create scalable solutions right from the start. Concepts such as design patterns, microservices, and distributed systems often take precedence, emphasizing the capacity to serve millions of users. However, in a startup environment, crafting scalable architectures can often turn into costly delays, leading us to focus on hypothetical users and potential issues rather than the immediate needs at hand.

By adopting my 3-Month Rule, I am compelled to write direct, sometimes “imperfect,” code that gets deployed quickly, allowing me to truly understand my users’ needs in real-time.

Current Hacks I’m Employing and Their Strategic Benefits

1. Unified Virtual Machine

All components of my platform—database, web server, background jobs, and caching—are hosted on a single $40/month virtual machine, with no redundancy and manual backups to my local system.

This approach has proven to be advantageous; within a mere two months, I’ve gained insights into my resource necessities that no amount of capacity planning could have provided. I discovered that my platform rarely requires more than 4GB of RAM. The complicated Kubernetes architecture I almost implemented would have resulted in idle resources.

When the system experiences downtime, which has occurred twice thus far, I receive actionable feedback on failures—turns out, it’s rarely what I anticipated.

2. Directly Hardcoded Configuration

Consider the simplicity of hardcoded values like:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"

With no configuration files or environment variables cluttering my code, any change necessitates a redeployment. This simplicity is actually powerful; I can quickly search my entire codebase for any configuration parameter