Embracing the 3-Month Rule: A Pragmatic Approach to Building Agile Software Solutions
In the startup world, conventional wisdom often echoes Paul Graham’s advice: “Do things that don’t scale.” However, translating this idea into a workable coding strategy is seldom discussed. After dedicating the last eight months to developing my AI podcast platform, I’ve crafted a straightforward yet effective framework: any unscalable workaround is given a trial period of exactly three months. If it proves valuable, it will be rebuilt for scalability; if not, it’s time to retire it.
The Shift from Engineer Thinking to Startup Reality
As engineers, we are conditioned to design scalable solutions from the outset. We often lean towards sophisticated architecture involving microservices and distributed systems, aiming to handle millions of potential users. This mindset, however, can lead to costly delays in early-stage startups. Instead of focusing on scaling solutions for users who may never exist, my three-month rule encourages creating straightforward, functional code that can be deployed quickly. This approach allows me to discover what users genuinely need rather than relying on assumptions.
My Practical Infrastructure Hacks: Insights and Benefits
Let me share some of the current non-scalable hacks I’ve implemented and the lessons I’ve learned from them:
1. Single-VM Setup
All core functionalities—database, web server, background jobs, and caching—are consolidated on a solitary $40/month virtual machine, with zero redundancy and manual backups.
This seemingly naive approach has enabled me to gain insights into my actual resource requirements far more quickly than any planning document could offer. Interestingly, the peak demand for my “AI-rich” platform was only 4GB of RAM. The complex Kubernetes infrastructure I was tempted to establish would have been managing largely idle resources. When the system crashes (which it has), I gain genuine insights into what causes issues, often surprising me.
2. Hardcoded Configurations
Configurations such as pricing tiers and user limits are directly embedded in the code, with no separate config files. Changes necessitate a redeployment.
Remarkably, this method allows me to quickly search for any configuration across the entire codebase. My git history meticulously tracks all changes. In three months, I’ve updated configurations just three times, resulting in minutes of redeployment versus hours of development time I would have spent building a more complex configuration service.
3. SQLite for Production Use
Yes, I’ve opted for SQLite in a multi-user app
One Comment
This is a fantastic articulation of the pragmatic mindset needed in early-stage product development. Your 3-month rule aligns well with the “build fast, iterate faster” philosophy, allowing teams to validate assumptions without over-investing upfront. I particularly appreciate the emphasis on measurable outcomes—if a workaround proves valuable within this timeframe, it can be thoughtfully scaled; if not, it’s efficiently retired.
Your examples, like using a single VM and SQLite in production, highlight the importance of simplicity and real-world feedback over complex, hypothetical architectures. It’s a reminder that understanding actual user behavior and system demands should drive architecture decisions, especially in the initial phases.
One insight that might add value: consider documenting and analyzing the failure points experienced during these shortcuts. Lessons from crashes or bottlenecks can inform targeted investments in scalability, rather than pre-emptive overengineering. Also, as your platform grows, gradually incorporating more modularity could help transition from these hacks to more robust solutions without losing agility.
Thanks for sharing this practical approach—it’s a valuable perspective for founders and engineers trying to balance speed with technical responsibility.