The 3-Month Rule: A Practical Approach to Non-Scalable Coding
In the entrepreneurial realm of tech development, one piece of advice stands out: “Do things that don’t scale,” a mantra popularized by Paul Graham. However, the challenge often lies in executing this wisdom effectively, especially when it comes to coding.
After eight months of working on my AI podcast platform, I’ve adopted a technical framework that I call the 3-Month Rule. This approach dictates that any non-scalable hack I implement has a lifespan of exactly three months. By that time, it must demonstrate its worth and transition into a more refined solution, or face removal.
In the world of engineering, we are taught to prioritize scalable solutions right from the start. We often dive into complex architectures involving design patterns, microservices, and distributed systems, primarily suited for larger organizations. However, for a startup, such ambitious plans may represent delayed action. Instead of catering to future users who may or may not materialize, my 3-Month Rule encourages me to embrace simplicity and create straightforward code in a manner that is both functional and informative.
My Current Infrastructure Hacks and Their Strategic Rationale
1. Consolidated Services on a Single VM
At the heart of my platform, every essential service—database, web server, and background jobs—today resides on a single virtual machine costing only $40 per month, alongside manual backups to my local device.
Why is this a smart strategy? Within just two months, I gained invaluable insights regarding my actual resource needs—information that traditional capacity planning documentation could not have provided. My needs peaked at 4GB of RAM for an “AI-heavy” platform, which made my nearly drafted Kubernetes setup redundant.
When the inevitable crashes occur (and they will), they reveal data on what truly fails—insights that often defy my earlier assumptions.
2. Hardcoded Values in My Codebase
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
My code is littered with constants—no configuration files or environment variables here. Every alteration necessitates a redeployment.
This setup has a striking advantage: I can search through my codebase for any configuration value in mere seconds, and every change is documented in my git history. Over three months, I’ve altered these constants
