Embracing the Three-Month Rule: A Practical Approach to Unscalable Solutions in Startups
In the startup world, the popular wisdom espoused by Paul Graham—”Do things that don’t scale”—is well understood, yet the practical application of this advice often goes unexamined, particularly in the realm of coding.
Having spent the past eight months developing my AI podcast platform, I devised a straightforward framework for integrating these unscalable practices into my workflow: every temporary hack has a lifespan of just three months. After this period, it either demonstrates its worth and gets refined into a more permanent solution, or it is phased out entirely.
This approach challenges the conventional mindset in engineering, where we are typically trained to develop scalable solutions from the outset. While scalable architectures—think distributed systems or microservices—are essential in managing vast user bases, they tend to prioritize future needs over immediate realities. In the early stages of a startup, pursuing scalability can often lead to costly delays, optimizing for potential users that may never materialize. My three-month rule compels me to produce straightforward, albeit imperfect, code that can be released quickly, providing me with invaluable insights into user needs.
Ingenious Infrastructure Hacks Worth Sharing
1. Consolidating on a Single Virtual Machine
I have chosen to run my entire technology stack—including the database, web server, and background jobs—on a single virtual machine costing just $40 per month. There’s zero redundancy and all backups are manual.
Contrary to assuming this setup is suboptimal, it has taught me a great deal about my actual resource requirements. In a mere two months, I’ve identified that my “AI-heavy” platform peaks at 4GB of RAM. The complex Kubernetes configuration I nearly built would have involved managing empty containers, proving unnecessary. When my server does crash, which it has on two occasions, I gain real insights into system failures that are often unexpected.
2. Hardcoded Configurations
My codebase includes hardcoded values like:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
While it may seem inefficient, this structure enables speedy searches throughout my code with a simple grep command. Any alteration is tracked in git history, allowing me to conduct my own code reviews quickly. Creating a configuration service would have been an extensive process
