Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Solutions
In the tech world, the notion of “doing things that don’t scale,” originally coined by Paul Graham, often sparks a good deal of debate. Yet, what remains largely unexplored is the practical application of this principle within software development. After dedicating eight months to building an AI podcast platform, I have developed a straightforward philosophy: any unscalable tactic I implement must endure for just three months. If it demonstrates its value, it gets refined; if not, it gets discarded.
Why the 3-Month Rule?
As engineers, we’re conditioned to focus on scalable solutions right from the outset. We gravitate towards intricate design patterns, microservices, and distributed systems—ideal for handling vast user bases. However, in a startup environment, focusing on scalability can often translate to costly delays. We tend to optimize for hypothetical users while grappling with challenges that may never arise. My three-month strategy compels me to embrace simpler, often flawed solutions that can be quickly deployed, ultimately shedding light on what my users truly need.
Current Tactical Implementations That Prove Effective
1. Consolidated Operations on a Single VM
Currently, my database, web server, background jobs, and caching are all running on a single virtual machine costing $40 a month. While this setup lacks redundancy and relies on my manual backups, the insights gained have been invaluable. Over just two months, I’ve gained a clear understanding of my actual resource consumption—my system peaks at about 4GB of RAM. The complex Kubernetes environment I nearly opted for would have left me managing virtually empty containers.
When the system encounters issues (which it has, twice), I gather concrete data on the exact points of failure. Interestingly, it’s rarely what I anticipated.
2. Hardcoded Constants for Configuration
For configuration settings, I rely on hardcoded values scattered throughout my code:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
This approach might seem simplistic, but it allows me to easily search my entire codebase and track any changes through Git history. I’ve only updated these variables three times in the last three months—making it far more efficient to redeploy than to build an extensive configuration service.
One Comment
This is a compelling approach that highlights the value of rapid experimentation and learning in early-stage development. The 3-Month Rule serves as an effective discipline to prevent over-engineering and encourages a focus on real user feedback rather than hypothetical scalability concerns. Your example of consolidating operations onto a single VM and using hardcoded constants demonstrates how lightweight, unscalable solutions can deliver immediate insights and inform subsequent decisions.
One additional aspect to consider is the iterative nature of this approach—after the initial three months, assessing performance, user growth, and operational stability will be crucial. This feedback loop can help determine whether scaling efforts are justified or if your current solutions are sufficient for your growth phase.
Moreover, embracing simplicity in the early stages often fosters a culture of agility, allowing you to pivot quickly based on what truly resonates with your users. As your project matures, gradually integrating more scalable systems can then be driven by data rather than assumptions.
Thanks for sharing this practical framework—it’s a valuable reminder that in the startup phase, speed and learning often trump perfect architecture.