The 3-Month Rule: A Practical Approach to Unscalable Coding for Startups
In the tech community, Paul Graham’s mantra of “Do things that don’t scale” is widely recognized, yet its application in programming rarely gets the attention it deserves. Experienced engineers are often conditioned to prioritize scalable solutions, leading to sophisticated architectures that might not be necessary in the early stages of a project. This is especially true in the startup landscape, where resources are limited, and versatility is paramount.
After eight months of developing my AI podcast platform, I’ve implemented a straightforward strategy: every unscalable approach I use is given a lifespan of just three months. This timeframe serves as both a test and a learning period—either the approach proves its worth and transitions into a sustainable solution, or it is phased out.
Why the 3-Month Rule Works
As developers, we tend to focus early on building architectures suitable for high user volumes—think microservices, distributed systems, and intricate design patterns. However, this often leads to investing in infrastructure for a user base that doesn’t yet exist. By embracing the 3-month rule, I’ve been able to prioritize development efforts that directly address the immediate needs of my current user base, implementing straightforward, less polished solutions that nevertheless yield crucial insights.
Current Strategies in Action
Let’s explore some of my current non-scalable approaches, each providing valuable lessons:
1. Single VM for Everything
All components—database, web server, background jobs—operate on a single $40 per month VM. There’s no redundancy and backups are done manually to my local system.
Why it Works: In just two months, this setup has clarified my resource needs far more than any exhaustive planning document. I’ve discovered that my platform’s peak usage requires only 4GB of RAM, meaning the complex Kubernetes environment I almost created would have been an inefficient use of resources.
2. Hardcoded Configuration
I manage configuration by using hardcoded constants throughout my codebase:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
The Benefit: Changing configurations requires a quick redeploy, which I’ve done only a handful of times. This approach enables incredibly swift searches through the code to identify any configuration values.
3. Using SQLite in Production
My current database setup involves
One Comment
This is a compelling insights into how embracing unscalable solutions early on can accelerate learning and reduce wasted effort. The 3-Month Rule effectively encourages experimentation without the fear of overengineering — a mindset crucial for startups where agility and rapid feedback are paramount. I especially appreciate the emphasis on using simple, tangible infrastructure like a single VM and hardcoded configs to gain real-world insights quickly. It’s a good reminder that building the right scalable architecture comes after validation and clarity, not before.
One addition I’d suggest is to pair this approach with clear exit criteria—knowing exactly when to re-evaluate and transition to more scalable setups. This way, the initial unscalable solutions serve as learning tools rather than becoming permanent constraints. Thanks for sharing this practical framework!