Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Coding
In the startup world, the advice from Paul Graham to “do things that don’t scale” often echoes. However, translating this wisdom into practical coding strategies can be a challenge. After eight months of developing my AI podcast platform, I’ve devised a straightforward framework: any unscalable workaround I implement is given a lifespan of three months. If it proves its worth within that timeframe, it earns the right to be developed further; if not, it gets scrapped.
The startup Dilemma: The Trap of Scalability
As engineers, we tend to gravitate towards scalable solutions from the get-go. We envision intricate designs, microservices architecture, and distributed systems—all optimized for an ever-growing user base. However, at a startup, focusing on scalability too early can be counterproductive, often leading to unnecessary complexity and expense while catering to hypothetical users. My 3-Month Rule encourages me to create straightforward, sometimes poorly designed code that facilitates immediate deployment, allowing me to better understand users’ actual needs.
Current Infrastructure Strategies: Smart & Simple
1. Consolidating on a Single VM
Currently, I’m running all my services—database, web server, background tasks, and Redis—on a single virtual machine for just $40 a month. While it may seem risky, this setup has proven invaluable. Within just two months, I’ve gained insights into my resource requirements that any capacity planning document couldn’t provide. For example, my AI platform peaks at just 4GB of RAM, which means the complex Kubernetes system I nearly set up would have simply managed redundant, unused containers. Plus, when crashes occur (and they have), I receive real data on what truly fails, often revealing surprises.
2. Hardcoded Configuration
My code features hardcoded constants like:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
No complex configuration files or environment variables to deal with. While some may see this as inefficient, it allows for swift searches across my entire codebase. Each price modification gets recorded in Git’s history, and I conduct my own code reviews for updates. Setting up a configuration service could take a week, yet I’ve only changed these values three times in three months—saving hours of engineering time.
