Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Solutions in Tech
In the tech world, advice often echoes through the halls, notably Paul Graham’s famous maxim: “Do things that don’t scale.” While this sentiment is widely acknowledged, the process of applying it, especially in coding, is rarely discussed. As someone who has spent the last eight months developing an AI podcast platform, I’ve crafted a straightforward yet effective methodology: every non-scalable solution I implement is given a lifespan of just three months. After this period, it either proves its utility and gets developed further, or it’s discarded altogether.
As engineers, our training typically steers us towards building solutions that can handle scalability from the get-go. We often find ourselves wrapped up in employing design patterns, microservices, and distributed systems—architectures designed to accommodate millions of users. However, this mindset often reflects that of larger corporations.
In a startup environment, focusing on scalable solutions can lead to expensive procrastination. We may end up optimizing for potential users who may never arrive, addressing problems that might not exist. My 3-month rule encourages me to write straightforward, direct, and sometimes “imperfect” code. This approach ensures that I deliver actual products and provides valuable insights into what my users genuinely require.
Here are some of my current infrastructure hacks and the wisdom behind them:
1. Consolidated Resources on One Virtual Machine
I’ve opted to run everything—database, web server, background tasks, Redis—on a single $40/month virtual machine without redundancy, relying on manual backups to my local machine.
Why is this a smart strategy? In just two months, I’ve gained a clearer understanding of my actual resource needs than any lengthy capacity planning document could provide. The reality of my “AI-heavy” platform is that it peaks at 4GB of RAM. My initial plans for a complex Kubernetes setup would have led to managing idle containers.
Whenever the system crashes (which has happened twice), I receive pertinent data about what actually goes wrong—surprising me every time with unexpected insights.
2. Hardcoded Configuration for Simplicity
Instead of relying on configuration files or environment variables, I use constants directly in my code:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
While this may sound
One Comment
Thank you for sharing this insightful approach. The 3-month rule is a compelling way to balance rapid experimentation with strategic reflection, especially in a startup context where time and resources are limited. I appreciate how you emphasize the value of quick, imperfect solutions—what Paul Graham advocates as “doing things that don’t scale”—to gain real-world insights early on.
Your example of consolidating resources onto a single VM exemplifies how initial simplicity can provide clarity about actual needs, avoiding premature optimization. It’s a reminder that sometimes, straightforward, non-scalable solutions can serve as effective learning tools, enabling us to build a foundation rooted in real user behavior and feedback.
Additionally, your practice of using hardcoded configurations underscores the importance of keeping things simple during early development phases. This flexibility allows for rapid iterations and minimizes boilerplate, which can later be refactored as the product matures.
Overall, your methodology encourages a pragmatic mindset—prioritizing tangible progress and learning over premature perfection—and it’s a valuable perspective for engineers navigating fast-paced environments. Looking forward to seeing how these tools evolve as your platform grows!