Embracing the 3-Month Rule: A Practical Framework for Startups
In the world of startups, advice often circulates about the need to “do things that don’t scale,” a notion popularized by Paul Graham. However, the implementation of this philosophy in the realm of coding is seldom discussed. Over the past eight months of developing my AI podcast platform, I’ve adopted a straightforward yet effective strategy: each unscalable hack is granted a lifespan of three months. Within that period, it either demonstrates its value and earns a place in the permanent architecture, or it is retired.
Understanding the Need for a Shift in Mindset
As engineers, we are naturally inclined to develop scalable solutions from the outset. We often think in terms of design patterns, microservices, and distributed architectures that can accommodate massive user bases. However, this mindset can be misleading for a startup, where the pursuit of scalability might translate to costly delays. My three-month rule compels me to prioritize simplicity by writing straightforward, sometimes “imperfect,” code that allows me to glean insights into user needs.
My Current Technical Hacks: Smart Simplicity in Action
1. A Single Virtual Machine
All components of my application—including the database, web server, background jobs, and Redis—operate on a single virtual machine (VM) costing only $40 a month. This approach lacks redundancy and relies on manual backups to my local machine.
The value in this setup lies in the real-world data I’ve acquired about my resource requirements over two months. My platform, anticipated to be “AI-heavy,” actually peaks at just 4GB of RAM. The complex Kubernetes architecture I initially considered would have inadvertently led me to manage empty containers. Each time the system crashes (which has occurred twice), I gain crucial insights into what truly fails—often surprising me.
2. Hardcoded Configurations
With constants like:
python
PRICE_TIER_1 = 9.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
My configurations are hardcoded. This means there are no environment variables or separate config files. While this sounds primitive, it offers a unique advantage: I can quickly search my entire codebase for any configuration value. Changes are tracked in version history and are subject to review, even if it’s just me checking my own pull requests.
Implementing a dedicated configuration service would have taken a week, whereas I’ve adjusted these values
