The Three-Month Framework: A Pragmatic Approach to Unscalable Solutions
In the tech world, the phrase “Do things that don’t scale,” famously coined by Paul Graham, is often echoed. However, the practical implementation of this advice, especially in programming, is rarely discussed. After eight months of developing my AI podcast platform, I’ve devised a straightforward approach: every unscalable technique is given a lifespan of three months. If it proves valuable, it’ll be polished; if it doesn’t, it will be discarded.
As engineers, we typically aim to create scalable solutions from the outset. We often get caught up in design frameworks like microservices and distributed architectures—all in an effort to accommodate a potentially vast user base. However, this often translates to delays at startups, where optimizing for future users means ignoring the immediate needs at hand. My three-month rule compels me to produce simple, albeit imperfect, code that can be effectively deployed, allowing me to genuinely understand user requirements.
My Current Strategies: Lessons from Unconventional Choices
1. Consolidation on a Single VM
At present, my database, web server, background jobs, and caching are all hosted on a single $40/month virtual machine. This approach offers zero redundancy and relies on manual backups to my local system.
Why is this approach clever? In just two months, I’ve gained a clearer insight into my resource needs than I would have from any theoretical capacity document. My so-called “AI-intensive” platform generally maxes out at just 4GB of RAM. The intricate Kubernetes architecture I almost implemented would have meant managing a plethora of idle containers.
Whenever the system does crash—yes, it’s happened twice—I’m getting actionable data about the real issue, and interestingly, it’s rarely what I anticipated.
2. Hardcoded Configuration Parameters
Consider this sample of my code:
plaintext
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
I’ve opted not to use configuration files or environment variables, choosing instead to hardcode constants throughout my application. Each change requires a redeployment.
The hidden advantage? I can search my entire codebase for any configuration value in mere seconds. Changes to pricing are easily tracked in my Git history and each modification undergoes a self-review process (which, admittedly, involves me reviewing my own pull requests).
Setting
One Comment
This is a compelling approach that highlights the importance of balancing rapid iteration with practical, hands-on understanding. Your three-month rule effectively cuts through the inertia that often accompanies designing highly scalable but complex systems prematurely—especially in the early stages of a project when immediate learning and validation are crucial.
I especially appreciate the emphasis on deploying simple infrastructure like a single VM and using hardcoded configurations for rapid experimentation. These tactics not only reduce initial overhead but also provide invaluable real-world data that can inform more scalable solutions down the line. As you correctly note, sometimes the most unglamorous setups can yield the clearest insights.
One thought for future iterations might be to implement a lightweight abstraction layer or toggle system for configurations—allowing quick switches without full redeployment—if certain parameters shift frequently. This preserves the agility you champion while slightly reducing manual overhead.
Overall, your framework underscores that embracing unscalable techniques temporarily is a strategic move—one that fosters genuine understanding and prevents over-engineering early on. Thanks for sharing this practical perspective!