Embracing the 3-Month Rule: A Pragmatic Approach to Development
When it comes to startup culture, the mantra often echoed is Paul Graham’s: “Do things that don’t scale.” However, the challenge lies in translating this wisdom into practical code development strategies. Over the past eight months, while crafting my AI podcast platform, I have devised a straightforward framework: each unscalable hack is permitted a lifespan of three months. At the end of this period, it must either demonstrate its value and be appropriately refined or face removal.
As engineers, we commonly lean towards creating scalable solutions from the outset. We’re trained to think in terms of sophisticated design patterns, microservices, and distributed systems—architectures that can support millions of users. Yet, this mindset often aligns with larger enterprises rather than the lean approach of startups. In a startup environment, focusing on scalable solutions can frequently lead to costly delays, as we devote time to optimizing for users who have yet to materialize, addressing challenges that may never arise.
The three-month rule compels me to generate straightforward and effective code that can be deployed quickly, granting me insights into the actual needs of my users. Here are the key infrastructure approaches I’ve adopted and the rationale behind them:
1. Consolidating Everything on a Single VM
Currently, my entire infrastructure—including the database, web server, background jobs, and Redis—operates on one affordable VM. With a modest cost of $40 per month, I sacrifice redundancy and perform manual backups to my local machine.
Why is this advantageous? In just two months, I’ve gained a clearer understanding of my resource requirements than any formal capacity planning document could provide. It turns out that my so-called “AI-heavy” platform only peaks at 4GB of RAM. The complex Kubernetes setup I nearly pursued would have been wasted on managing empty containers. Moreover, when crashes occur—twice thus far—I gather genuine data regarding failure points, which have consistently surprised me.
2. Embracing Hardcoded Configurations
My configuration strategy consists of hardcoded values scattered throughout my codebase. This includes constants like:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
Though lacking in sophistication, this method allows me to quickly search for any configuration value across the codebase and ensures that every price adjustment is preserved
