The 3-Month Rule: A Pragmatic Approach to Development in Startups
In the entrepreneurial landscape, the advice from Paul Graham resonates strongly—“Do things that don’t scale.” However, translating this principle into practical coding strategies is often overlooked. Throughout my journey of developing an AI podcast platform over the past eight months, I’ve devised a straightforward framework: any unscalable workaround I implement is assigned a lifespan of three months. After this period, it either proves its value and gets refined, or it gets discarded.
As engineers, we often find ourselves fixated on creating scalable solutions from the outset. We learn to admire complex architectures, including design patterns, microservices, and distributed systems—ideal for handling millions of users. Yet, this mindset can be particularly detrimental in the startup world, where scalable code may simply represent costly procrastination. My three-month rule encourages me to embrace simplicity and directness, allowing me to write ‘bad’ code that actually gets deployed, thus revealing valuable insights into user needs.
Current Infrastructure Experiments and Their Unexpected Benefits
1. Consolidated Operations on a Single VM
I run my database, web server, background jobs, and Redis, all on a single $40/month virtual machine. This approach, while lacking redundancy and relying on manual backups, has given me unprecedented insights into my resource requirements. I’ve discovered my platform’s peak usage is merely 4GB RAM. The complex Kubernetes setup I had considered would have led only to managing idle containers.
Each crash (which has happened twice) provides concrete data on failure points—typically differing from my original assumptions.
2. Hardcoded Configuration for Simplicity
Instead of employing configuration files or environment variables, I use hardcoded constants across my scripts:
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
While some may see this as an oversight, it allows me to quickly search for any configuration value through the entire codebase. Changes are straightforward, requiring less than 15 minutes of redeployment instead of investing a week in creating a configuration service—especially considering that I’ve only modified values three times in three months.
3. Utilizing SQLite for Production
Yes, my multi-user web application operates on SQLite. With a database size of just 47MB, it handles up to 50 concurrent users effortlessly
