The 3-Month Rule: A Pragmatic Approach to Unscalable Coding Practices
When it comes to navigating the tech landscape, few phrases resonate as powerfully as Paul Graham’s advice: “Do things that don’t scale.” While this concept is frequently discussed in entrepreneurial circles, its application in coding practices often remains murky.
After spending eight months developing my AI podcast platform, I’ve established a simple yet effective framework: each unscalable technique is granted a lifespan of three months. At the end of this period, if the method proves its worth, it gets the investment it deserves; otherwise, it gets cut from the project.
The Challenge of Scalability in a Startup Environment
As engineers, we often find ourselves conditioned to pursue scalable solutions from the outset. The allure of well-architected systems—microservices, distributed architectures, and intricate design patterns—can be enticing. However, this mindset is more suited to established companies rather than startups.
In a startup context, the quest for scalability can sometimes devolve into costly procrastination. It prompts us to optimize for future users who may never materialize and to solve issues that might not even be relevant. My three-month rule compels me to embrace simple, straightforward, yet “imperfect” code that these hacks allow me to deploy swiftly. This approach not only expedites the shipping process, but also helps me better understand my users’ needs.
My Current Unscalable Infrastructure and the Wisdom Behind It
1. Consolidation on a Single VM
I’ve chosen to run my entire stack—including the database, web server, background jobs, and Redis—on a single virtual machine for just $40 a month. This setup lacks redundancy and relies on manual backups to my local drive.
Why is this strategy smart? Within two months, I’ve gained more insights into my actual resource requirements than I ever could have from formal capacity planning documents. My “AI-heavy” platform peaks at 4GB RAM, which makes my former plan for a complex Kubernetes setup unnecessary—most of those resources would have remained idle.
Plus, each time the system crashes (which has happened twice), I gain invaluable information about the failure points—insights that often surprise me.
2. Simplified Hardcoded Configuration
In my code, you’ll find constants like:
“`plaintext
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL
One Comment
This is a fantastic approach that emphasizes the importance of rapid experimentation and learning in the early stages of product development. The 3-month rule effectively balances the need for immediate progress with the practicality of evaluating what truly adds value. By embracing unscalable practices initially—such as consolidating everything on a single VM or hardcoding configurations—you free up time and mental bandwidth to focus on core functionality, user feedback, and nuanced understanding of actual requirements.
Moreover, your mindset resonates with the concept of “lean startup,” where validated learning takes precedence over perfect architecture. It’s refreshing to see a pragmatic framework that encourages iterating quickly without being hamstrung by premature scalability concerns. As you gather insights over these three months, your decisions about whether to refactor or optimize will be grounded in real usage data rather than assumptions.
This approach can serve as a valuable template for early-stage teams: prioritize speed and learning, set clear time-bound experiments, and be willing to shed what doesn’t prove its worth. Thanks for sharing this insightful perspective!