Embracing the Imperfect: The 3-Month Rule for Product Development
In the startup world, the phrase “do things that don’t scale” is often quoted, particularly in the context of product development. However, the conversation rarely dives into the specifics of how we actually apply this principle in our coding practices. After eight months of developing my AI podcast platform, I’ve devised a straightforward yet effective framework: I give every unscalable hack a lifespan of three months. At the end of this period, it must either demonstrate its worth and be transformed into a robust solution, or it faces elimination.
Redefining Scalability
As engineers, we tend to gravitate towards scalable solutions right from the start. We often get lost in complex systems—design patterns, microservices, and distributed architectures—aimed at servicing millions of users. However, the reality of startup life is that such scalability can sometimes translate into costly procrastination. We find ourselves spending time optimizing for hypothetical users and resolving issues we may never actually face.
By adhering to my 3-month rule, I focus on writing simple, efficient code that gets deployed quickly. This approach enables me to uncover what my users truly need rather than relying on assumptions.
Current Infrastructure Hacks: Smart Decisions for Learning
Here’s a breakdown of a few unconventional strategies I’m currently employing that prove to be not only practical but enlightening:
1. Consolidating on One VM
I’ve chosen to run my database, web server, background jobs, and Redis on a single $40/month virtual machine. While this setup lacks redundancy and relies on manual backups, the insights I’ve gained have been invaluable. In just two months, I acquired an understanding of my actual resource demands far superior to any capacity planning document could offer. For instance, my platform’s peak usage only requires 4GB of RAM, highlighting that my elaborate plans for a Kubernetes infrastructure might have just been overkill.
2. Simplicity in Configuration
I have opted for hardcoded configuration variables scattered throughout my code, eliminating the need for complex config files or environment variables. This simplicity allows me to quickly search for any configuration value, keeping track of price changes through git history. The time saved with this streamlined approach—less than 15 minutes of deployment versus potentially 40 hours of software engineering—is significant.
3. Utilizing SQLite in Production
In a twist that many might find controversial, I’m running SQLite for my multi-user
One Comment
Thank you for sharing such a practical and thought-provoking approach to balancing speed and sustainability in product development. The 3-month rule beautifully encapsulates the essence of learning through iteration—allowing for quick experimentation while maintaining accountability for outcomes. I particularly appreciate your emphasis on starting simple and refining over time; it echoes the Lean Startup principles of build-measure-learn.
Your infrastructure hacks demonstrate that sometimes, less is more. Running everything on a single VM, using hardcoded configs, and even deploying SQLite in production—these choices might seem unorthodox but serve as valuable learning tools and cost-effective solutions in the early stages. They highlight the importance of validating assumptions early on before scaling complexity.
This approach also emphasizes that, especially in startups, building scalable solutions from day one can lead to unnecessary delays. Instead, focusing on “good enough” for now, with a clear plan to reassess in three months, fosters agility and real user insights.
Have you considered documenting these learnings as part of a living post-mortem or retrospective? It could provide even more clarity and guidance for others navigating similar challenges. Thanks again for sparking a meaningful discussion about pragmatic engineering!