Embracing the 3-Month Rule: A Practical Approach for Startups
In the startup world, we are often reminded of the wisdom imparted by Paul Graham: “Do things that don’t scale.” However, the challenge lies in translating this advice into actionable strategies, particularly in software development. Over the past eight months, while working on my AI podcast platform, I have crafted an approach I refer to as the “3-Month Rule.” This framework allows unscalable hacks to thrive for three months; after this period, they either prove their worth and are developed further or are phased out.
As engineers, our instinct often drives us toward creating scalable solutions right from the onset—think design patterns, microservices, and robust architectures capable of accommodating vast user bases. However, this kind of thinking suits larger organizations better than startups, where building for scale can frequently translate to wasted effort and resources, delaying real user learning.
My 3-month rule encourages me to embrace straightforward, albeit imperfect, coding solutions that deliver results, allowing me to discover the true needs and behaviors of my users.
Current Infrastructure Hacks: A Strategic Perspective
Here are some of the deliberate ‘hacks’ I’ve implemented and the insightful lessons they have taught me:
1. Consolidated Operations on a Single VM
Currently, my entire infrastructure—database, web server, background jobs, and caching—all operates on a single virtual machine for just $40 a month, without any redundancy or automated backups.
Why does this make sense? In just two months, I’ve gained invaluable insights about my resource requirements that no theoretical capacity planning could have provided. Interestingly, my “AI-intensive” platform only peaks at 4GB of RAM. The intricate Kubernetes setup I had considered would have left me managing unused resources.
When the system crashes (which it has a couple of times), I receive immediate, practical insights about what failed—information I wouldn’t have garnered otherwise.
2. Hardcoded Configuration Values
Instead of relying on external configuration files or environment variables, I have opted to hardcode values such as pricing tiers or limits directly into the code.
This may seem inefficient, but it offers significant advantages. I can quickly search my entire codebase for any configuration value, with the entire history of price changes easily tracked through git. Moreover, making these changes translates to a modest redeployment time, sparing me from the tedious process of building a configuration service that would have taken days to implement
