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

In the startup world, advice often echoes through the halls: “Do things that don’t scale.” While this concept, famously championed by Paul Graham, resonates with entrepreneurs, many overlook its practical implementation—especially in the realm of software development.

Having spent the past eight months developing my AI podcast platform, I’ve adopted a straightforward method: every temporary, unscalable hack is given a 3-month lifespan. This strategy allows me to evaluate its effectiveness, paving the way for either a robust solution or its retirement.

Let’s face it—engineers are predominantly trained to build scalable systems from the outset. We become enamored with design patterns, microservices, and distributed architectures, all the while preparing for an influx of users. However, in the context of a startup, this approach can often serve as an expensive form of procrastination, focusing on hypothetical problems instead of real user needs. The 3-month rule motivates me to write straightforward, even “imperfect,” code that swiftly solves immediate challenges and uncovers genuine user requirements.

Current Hacks and Their Surprising Merits

1. Consolidating Everything on One VM

Currently, my web server, database, background tasks, and Redis operate on a single $40/month virtual machine (VM). While some may view this as a reckless strategy, I see brilliance in it. Over the past two months, I have gained invaluable insights into my actual resource requirements—something no capacity forecast could provide. My platform, surprisingly, maxes out at 4GB of RAM. Had I invested time setting up a complex Kubernetes infrastructure, I’d be managing idle containers instead of focusing on what truly matters.

2. Utilizing Hardcoded Configuration

I rely on hardcoded configurations, such as:

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

This method eliminates the need for configuration files or environment variables. Each change requires a redeployment, but the simplicity allows quick searches across my codebase. In three months, I’ve adjusted configurations a mere three times, saving countless engineering hours.

3. Running SQLite in Production

Yes, I’ve opted for SQLite for a multi-user application. With a total database size of 47MB, it efficiently supports up to 50 concurrent users