The 3-Month Rule: A Practical Approach to Non-Scalable Coding
In the world of startup development, advice like Paul Graham’s “do things that don’t scale” is often echoed, yet the application of this principle in the realm of coding rarely receives the attention it deserves. Having spent the last eight months constructing my AI podcast platform, I’ve crafted a straightforward yet effective framework: I give every non-scalable solution three months to either demonstrate its value or be shelved.
As engineers, we’re frequently trained to pursue scalable solutions from the very beginning—think design patterns, microservices, and complex distributed systems designed for vast audiences. However, this mindset can become counterproductive, especially in a startup context where crafting scalable code may inadvertently lead to procrastination and wasted resources. My three-month rule compels me to adopt simpler, more direct coding practices that lead to rapid deployment and insightful user feedback.
Current Infrastructure Strategies: Smart Simplicity
Here’s an overview of some current infrastructure strategies I’ve implemented that might seem unconventional, yet prove to be incredibly beneficial:
1. Single VM for Everything
I run my entire operation—including the database, web server, background jobs, and Redis—on a single $40/month virtual machine. While this approach features minimal redundancy and requires manual data backups, it has offered invaluable insights into my actual resource needs far beyond what any capacity-planning document could provide.
For example, I’ve discovered that my “AI-heavy” platform typically requires only 4GB of RAM. The extensive Kubernetes setup I nearly initiated would have resulted in resource management for unused containers. With the VM crashing a couple of times, I gathered real data about system failures and learned that these incidents often stemmed from unexpected issues.
2. Hardcoded Configuration Values
Instead of using configuration files or environment variables, I keep all my constants—such as pricing tiers and maximum user capacity—hardcoded throughout the codebase. While this may appear simplistic, it offers a unique benefit: I can quickly search for configuration values throughout the entire codebase, and each change is precisely tracked in version control.
Building a complex configuration service would have taken up to a week. In practice, I’ve modified these values only three times in three months, leading to minimal redeployment time compared to the hours that would have been needed for more elaborate solutions.
3. Using SQLite in Production
Surprisingly, I’m utilizing SQLite for my multi-user web application. Given that the database size is
One Comment
This post offers a compelling perspective on balancing rapid experimentation with practical infrastructure management, especially in startup contexts. I appreciate the emphasis on the “3-Month Rule” as a disciplined approach to evaluate the viability of non-scalable solutions early on—ensuring resources are efficiently allocated toward what truly adds value.
Your choice to prioritize simplicity, such as running everything on a single VM and hardcoding configuration values, aligns well with the principle of “building fast and learning fast.” It reminds me of the concept of *minimum viable infrastructure*, which can be crucial for early-stage testing and iterative development.
Using SQLite in production is unconventional but can be a strategic choice during the initial phases, where the overhead of managing a more complex database might hinder agility. It allows you to focus on core features and user feedback without being bogged down by infrastructure complexity.
Overall, your framework is a practical blueprint for startups aiming to avoid the trap of over-engineering and instead focus on real-world validation. It would be interesting to explore how you plan to evolve this infrastructure as your platform scales beyond the initial three-month trial or when user load increases significantly.