The 3-Month Rule: A Technical Framework for Embracing the Unscalable

In the world of startups, the advice from renowned entrepreneur Paul Graham rings true: “Do things that don’t scale.” However, the discussion often stops short of practical implementation, especially in the realm of coding. After eight months of developing my AI podcast platform, I’ve established a straightforward framework that I call the “3-Month Rule.” This method allows me to experiment with unscalable hacks for a limited time—three months to be exact. At the end of this period, each approach either proves its worth and evolves into a more robust solution, or it gets the axe.

As engineers, we are conditioned to prioritize scalable solutions from the outset. The allure of design patterns, microservices, and distributed systems can be overwhelming, as we envision architectures that can support millions of users. Yet, in the startup environment, pursuing scalability too early is often a costly detour. My 3-Month Rule compels me to write straightforward, albeit imperfect, code that delivers real results and uncovers genuine user needs.

Current Infrastructure Strategies: Pragmatic and Insightful

1. Single Virtual Machine Setup

Currently, everything from the database to the web server and background jobs runs on a single $40/month virtual machine. While it lacks redundancy and relies on manual backups, this approach has been enlightening. In merely two months, I’ve gained invaluable insights into my resource requirements. I discovered that my “AI-heavy” platform peaks at just 4GB of RAM, rendering my initial plans for a Kubernetes setup unnecessary. Since the crashes have occurred twice, I’ve gathered concrete data about system vulnerabilities—information I wouldn’t have gleaned otherwise.

2. Hardcoded Configuration

Instead of utilizing configuration files or environment variables, I have implemented simple constants within my code:

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

Changing a value mandates a redeployment, but I can quickly search for any configuration option across the codebase. Each price adjustment is logged in the git history, and I self-review every change. Building a complex configuration service could take a week, but in three months, I’ve made only three changes—saving countless hours of engineering time.

3. SQLite for Production Use

Surprisingly, I’m currently using SQLite for a multi-user application,