The 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions
In the startup world, there’s a well-known piece of advice from Paul Graham: “Do things that don’t scale.” While many recognize the value of this mantra, the challenge often lies in its practical application—particularly within the realm of coding.
Over the past eight months, while developing my AI podcast platform, I’ve devised a straightforward framework to put this philosophy into action: every unscalable solution is given a lifespan of just three months. After this period, we assess its relevance—either it showcases clear benefits and is upgraded into a more robust solution, or we remove it altogether.
As software engineers, we are often trained to focus on scalable solutions from the outset—think design patterns, microservices, and distributed systems, all designed to support millions of users. However, at a startup, diving headfirst into scalability can often equate to costly procrastination. We may end up optimizing for hypothetical future users while neglecting immediate needs. My 3-month rule encourages me to produce straightforward, albeit imperfect, code that can be deployed quickly and provides genuine insights into what users truly require.
Insights from My Current Non-Scalable Infrastructure
1. Single Virtual Machine Setup
My platform runs entirely on a single $40/month virtual machine that hosts everything: the database, web server, background jobs, and Redis. There’s no backup system in place—just manual backups saved to my local machine.
Why is this approach effective? Within just two months, I’ve gained a clearer understanding of my actual resource needs than any complex capacity planning document could provide. Surprisingly, my supposed “AI-intensive” platform only peaks at 4GB of RAM. The intricate Kubernetes architecture I contemplated would have only served to manage empty containers.
And when the system crashes (which has happened twice), I receive valuable insights into the true causes of failure—often, they’re not what I had anticipated.
2. Hard-Coded Configurations
I’ve opted for hardcoded constants sprinkled throughout my codebase for pricing and user limits, 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 involved, which means changes necessitate a redeployment. The benefit of this method? I can quickly
One Comment
Thank you for sharing this insightful approach. I really appreciate the pragmatic mindset behind the 3-Month Rule—it’s a powerful way to balance immediate experimentation with eventual iteration. Especially in startups, where time and resources are limited, embracing simple, non-scalable solutions upfront can reveal what truly resonates with your users, rather than investing heavily in features or architecture that might not be necessary at this stage.
Your example of using a single VM and hardcoded configurations highlights an important lesson: sometimes, simplicity accelerates learning. It reminds me of the “minimum viable product” philosophy—prioritizing quick deployment and real user feedback over premature optimization. The key is to stay flexible: as you gather data over these three months, you can identify which parts of your infrastructure genuinely need scaling or refactoring.
This approach also serves as a mental model to prevent perfectionism and scope creep, allowing teams to focus on learning and iterating rapidly. I believe this mindset is especially valuable for early-stage startups looking to avoid “gold-plating” their systems before validating core assumptions.
Looking forward to hearing how these insights translate into long-term scalability—perhaps your framework could evolve into a method for phased optimization, where initial agility is preserved until growth justifies a more robust architecture. Thanks again for sharing your experience!