Embracing the 3-Month Rule: A Practical Approach to Unscalable Solutions
When it comes to building successful tech projects, one piece of advice often resonates among entrepreneurs: “Do things that don’t scale.” This sage insight from Paul Graham encourages startups to focus on immediate user needs rather than get bogged down by the complexities of scaling from the outset. However, the challenge remains: how do you put this approach into practice, especially in coding?
After eight months of developing my AI podcast platform, I’ve devised a straightforward framework that I call the “3-Month Rule.” This rule stipulates that any unscalable hacks I implement are given a three-month lifespan. At the end of this period, the hack either proves its worth and is transformed into a more robust solution, or it is scrapped entirely.
The Problem with Traditional Thinking
As engineers, we often get trained to prioritize scalable solutions right from the start. We dream in terms of design patterns, microservices, and distributed systems—architectural complexities built to accommodate millions of users. However, this line of thinking is more aligned with large companies than with startups.
In a startup environment, focusing on scalability can often lead to costly delays, where we’re preparing for hypothetical users while neglecting the real ones. This is why my 3-Month Rule encourages me to write straightforward, even ‘suboptimal’ code that gets shipped quickly. Through this process, I gain deeper insights into what users genuinely need.
Current Unscalable Strategies: Why They Work
Let’s dive into some of the infrastructure hacks I’ve adopted and examine their unexpected benefits.
1. Consolidating on a Single VM
I’ve placed my database, web server, background jobs, and even Redis on a single $40/month virtual machine (VM). This approach may seem reckless due to the absence of redundancy and reliance on manual backups. Yet, it has offered invaluable insights into my resource requirements within just two months. I’ve discovered that my AI-heavy platform only peaks at 4GB of RAM. The complex Kubernetes configuration I had considered? It would have meant managing empty containers.
When my system has unexpectedly crashed (twice so far), I received genuine data about actual failures—none were what I anticipated.
2. Hardcoded Configuration Parameters
My code features hardcoded constants like this:
“`python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX
