The Three-Month Rule: A Pragmatic Approach to Non-Scalable Solutions
In the startup world, we often hear the famous advice from Paul Graham: “Do things that don’t scale.” While this principle is widely acknowledged, its practical application in software development is rarely discussed. After eight months dedicated to building my AI podcast platform, I’ve instituted a straightforward framework: each unscalable solution gets a lifespan of exactly three months. At the end of this period, it either demonstrates its value and evolves into a sustainable solution, or it’s discarded.
As engineers, we are instinctually trained to develop scalable architectures—think complex design patterns, microservices, and distributed systems that cater to millions of users. However, this approach can be detrimental in a startup setting, where scalability often equates to expensive procrastination aimed at hypothetical future users and problems. My three-month rule has empowered me to produce straightforward, albeit imperfect, code that delivers real insights into user needs.
Clever Infrastructure Hacks
Here’s a look at my current technical shortcuts and why they are surprisingly effective:
1. Consolidated on a Single VM
Everything from the database to the web server and background jobs operates on a single $40/month virtual machine, with no redundancy but manual local backups. This approach has granted me invaluable insights into my actual resource requirements in just two months. For instance, my AI platform requires only 4GB of RAM during peak times. The sophisticated Kubernetes setup I considered would have wasted resources managing empty containers. Plus, when crashes occur, I gather authentic data on what truly breaks—often unexpected elements.
2. Hardcoded Configuration Values
With constants such as:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
There are no configuration files or environment variables—just scattered constants across the codebase. Any changes necessitate redeployment, which has proven efficient. I’ve only modified the configurations three times in three months, translating to 15 minutes of redeployment compared to the week it would have taken to develop a configuration service. This approach allows me to quickly locate and track changes through Git history.
3. Using SQLite in Production
Currently, my multi-user web application operates on SQLite, which is surprisingly adequate with its 47MB database that comfortably supports 50 concurrent users. Through this experience, I’ve realized that my usage patterns lean
One Comment
Thank you for sharing your practical approach to balancing rapid iteration with the realities of startup development. The “3-Month Rule” concept is a compelling way to force prioritization—not just of features, but of the right architecture choices at the right time. I especially appreciate your emphasis on understanding actual resource needs through simplified infrastructure, rather than over-engineering from the outset.
Your use of a single VM and hardcoded configs exemplifies a mindset of “doing enough” to validate hypotheses quickly, which is often undervalued in larger systems. It also highlights how early-stage projects benefit from focusing on core value delivery rather than prematurely optimizing for scale—saving time and resources.
One aspect I’d suggest considering as you grow is planning for migration pathways. For instance, once certain features stabilize, transitioning from SQLite to a more scalable database or externalizing configurations can be smoother if you’ve structured your code with clear separation and versioning in mind. This way, you keep the agility of your initial approach while preparing for future scalability.
Overall, your framework effectively encourages a lean, feedback-driven engineering process—an approach that can generate valuable insights and avoid the trap of “perfect not yet implemented.” Looking forward to seeing how your platform evolves within this pragmatic context!