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

In the tech world, there’s a well-known piece of advice from Paul Graham: “Do things that don’t scale.” While this concept resonates widely, the question often arises—how do we truly apply it in software development? After dedicating eight months to building my AI podcast platform, I’ve devised a straightforward method: every unconventional, unscalable hack gets a lifespan of exactly three months. At the end of this period, it either proves its worth and evolves into a robust solution, or it’s phased out.

As engineers, we tend to be conditioned to prioritize scalability from the outset—focusing on design patterns, microservices, and distributed architectures that cater to millions of potential users. However, this mindset can lead to unnecessary complexity, especially in a startup environment where the demand is often unproven. By implementing my 3-month rule, I force myself to write straightforward and sometimes “imperfect” code that actually gets deployed and reveals real user needs.

Insightful Infrastructure Hacks and Their Benefits

1. One VM for Everything

I’m currently deploying my entire app—database, web server, background jobs, Redis—on a single $40/month virtual machine. While this setup lacks redundancy and relies heavily on manual backups, it has provided invaluable insights into my actual resource requirements far quicker than any capacity planning document could. For instance, my platform, which I anticipated to be resource-heavy, peaks at only 4GB of RAM. The complex Kubernetes setup I nearly implemented would have meant managing idle containers instead of learning from real-time analytics.

When failures occur (which they have, a couple of times), I gain immediate, actionable insights about what truly breaks—often unexpected things.

2. Hardcoded Configuration

In my code, configuration values—like pricing tiers and user limits—are hard-coded:

python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"

While this may seem simplistic, it allows me to quickly search for and modify values across the codebase. Each change is meticulously documented in Git history, and every update is carefully reviewed—even if it’s just me looking over my own pull requests. Developing a separate configuration service would have taken a significant time investment, yet I’ve only needed to change these