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
One Comment
This post beautifully highlights how embracing pragmatic, sometimes “unscalable” solutions can accelerate learning and validation during the early stages of a startup. The 3-month rule serves as a practical boundary—short enough to avoid prolonged commitment to flawed work, yet sufficient to gather meaningful insights. I particularly appreciate the emphasis on simplicity, such as consolidating infrastructure and hardcoding configurations, which aligns with the concept of “fail fast” and optimizing for rapid iteration.
It’s interesting to see how these approaches, like using SQLite for a small user base or running everything on a single VM, can provide valuable cost-efficient feedback and help identify real bottlenecks before investing in more complex, scalable solutions. Moreover, the mindset of being willing to discard or refine work after a short period fosters agility and reduces unnecessary technical debt—key traits for thriving startups.
Would love to hear more about how you plan to transition from these initial “unscalable” solutions as your platform scales—and how you balance the urge for simplicity with the need for future robustness. Great insights!