Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions
In the realm of software development, particularly in startup culture, there’s a mantra often echoed by Paul Graham: “Do things that don’t scale.” While the phrase is widely acknowledged, the implementation of this approach within coding practices remains less discussed. After dedicating eight months to building my AI podcast platform, I’ve devised a straightforward framework: any unscalable workaround gets a three-month trial period. Post this timeframe, it must either demonstrate its value and evolve into a robust solution or be discarded.
As engineers, our training often gravitates towards crafting scalable solutions from the outset. We get immersed in the intricacies of design patterns, microservices, and distributed systems—all appealing architectures intended to accommodate millions of users. However, this perspective is often more suited for larger enterprises.
Within a startup, focusing on scalability can become an exercise in costly procrastination. We may find ourselves fine-tuning features for hypothetical users, tackling challenges that may never arise. My three-month rule compels me to create straightforward, even “imperfect,” code that not only launches but also reveals genuine user needs.
Current Infrastructure Strategies: Learning from the Unconventional
1. Consolidating Everything on One VM
I run my database, web server, background tasks, and Redis on a single $40/month virtual machine. There’s no redundancy, and I manually back up to my local machine.
Why is this a good strategy? I’ve gained deeper insights into my actual resource requirements in just two months than any elaborate capacity planning could have provided. For instance, I’ve discovered that my platform’s peak usage only demands 4GB of RAM. The complex Kubernetes setup I nearly implemented would have resulted in managing largely idle containers.
During system crashes—two of which have occurred—I obtained valuable real data on failure points, which have proven to be surprising and not necessarily where I expected.
2. Hardcoded Configuration Values
Configuration values are directly embedded in the code. Consider:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
I rely on hardcoded constants scattered throughout various files, which means every change requires a redeployment.
The advantage here? I can quickly search my entire codebase for any configuration item. All price adjustments are logged in Git history,
