Embracing the 3-Month Rule: A Unique Approach to Development in Startups
In the startup landscape, there’s a well-known mantra from Paul Graham: “Do things that don’t scale.” However, there often seems to be a lack of discussion around how to effectively apply this advice within the world of coding. After eight months of developing my AI podcast platform, I’ve devised a straightforward framework — one that allows each unscalable solution a lifespan of just three months. At the end of this period, these solutions either prove their significance and earn the right to be fully developed, or they are phased out.
As engineers, we are typically trained to create scalable frameworks right from the start. We delve into advanced designs, microservices architecture, and distributed systems aimed at accommodating millions of users. However, this mindset resonates primarily with larger companies.
In a startup environment, focusing too heavily on scalability can often lead to unnecessary expenses and delays. We tend to optimize for future users who may never materialize, while neglecting the immediate necessity to understand and address our current users’ needs. My three-month rule encourages me to write straightforward, sometimes “imperfect” code that is functional and allows me to gain valuable insights into what users truly require.
Current Infrastructure Strategies and Their Unexpected Wisdom
1. One VM to Rule Them All
Right now, my entire setup — including the database, web server, background jobs, and caching — runs on a single $40/month virtual machine. There’s no redundancy in sight, and backups are conducted manually.
Why is this decision smart instead of foolish? Within just two months, I’ve gained insights into my actual resource demands that no capacity planning document could have provided. I discovered that my platform, which is perceived to be “AI-heavy,” only utilizes about 4GB of RAM at its peak. An elaborate Kubernetes configuration would have involved managing empty containers while not addressing my true needs.
When crashes occur (which they have, twice), I receive real, actionable data regarding the failures. Spoiler alert: The causes are never what I anticipated.
2. Hardcoding Configurations
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
There are no external configuration files or environment variables; constants are simply hardcoded in various files, requiring redeployment for any changes.
