Embracing the 3-Month Rule: A Pragmatic Approach to Coding for Startups
In the world of startups, the common wisdom from Paul Graham rings true: “Do things that don’t scale.” However, there is a noticeable gap in discussions around effectively implementing this principle in a coding context. After dedicating eight months to developing my AI podcast platform, I found a strategy that has worked wonders for me: the 3-Month Rule. This straightforward framework grants every unscalable fix a lifespan of three months, after which it either earns its place in my codebase or is discarded.
The Mindset Shift
As engineers, we are often conditioned to think in terms of scalability. We focus on creating sophisticated architectures, employing design patterns, and building distributed systems capable of handling large volumes of users. However, this is more aligned with the mindset of larger corporations than that of agile startups.
In startup environments, spending time on scalable solutions can lead to costly delays, as you’re often optimizing for hypothetical users and problems that may never arise. The 3-Month Rule challenges me to write straightforward, albeit imperfect code—code that actually gets deployed and provides insights into user needs.
My Current Infrastructure Strategies: Smart Hacks That Work
1. Single VM for Everything
Currently, my entire stack—from the database to the web server and background jobs—runs off a single $40/month Virtual Machine (VM). While it lacks redundancy and I rely on manual backups, this setup has provided invaluable insights into my resource requirements. After just two months, I’ve learned that my AI platform peaks at 4GB of RAM. Had I opted for a complex Kubernetes configuration, I would have wasted efforts managing unused resources.
When unexpected crashes occur, I’ve gathered data on actual failure points, which are often not what I initially anticipated.
2. Hardcoded Configuration
My code includes hardcoded values like:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
There are no configuration files or environment variables; every change necessitates a redeployment. The real advantage? I can swiftly search my entire codebase for any configuration value. Changes are meticulously tracked in Git, and a quick review ensures my modifications are relevant.
Opting for a dedicated configuration service would have cost me a week of development for something I’ve changed only
