Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Solutions
In the entrepreneurial tech landscape, there’s a well-known mantra from Paul Graham: “Do things that don’t scale.” Yet, the intricacies of putting this principle into practice—especially in software development—remain largely unaddressed. For the past eight months, as I’ve been working on my AI podcast platform, I’ve created a straightforward framework centered around this notion. I call it the “3-Month Rule.” Under this approach, any workaround or unscalable solution is allowed to exist for a maximum of three months. After this period, it either proves its worth and gets properly developed, or it gets the axe.
As engineers, we often find ourselves conditioned to create scalable solutions from the outset. We talk about implementing design patterns, microservices, and distributed systems—all aimed at accommodating thousands, if not millions, of users. This mindset is essential in larger organizations but can be a trap for startups.
In the early stages of a startup, chasing scalable solutions is often just a form of procrastination. You’re investing time and resources into solving challenges for users who might not even exist yet. By adhering to my 3-Month Rule, I’m encouraged to write simple, straightforward code that makes it to production quickly. This facilitates learning about actual user needs rather than relying on assumptions.
Current Infrastructure Hacks: Smart Decisions for Growth
1. Consolidating Resources on a Single VM
Everything from my database to my web server operates on a single $40/month virtual machine (VM). This includes Redis and background jobs—no redundancy in sight, and I handle backups manually.
Why is this a strategic choice? The past two months have taught me more about my resource requirements than any forecasting document could. My platform, which I initially believed would be resource-intensive, only requires about 4GB of RAM. Had I gone ahead with an intricate Kubernetes setup, I would have wasted resources on managing idle containers. Each crash—yes, it has happened twice—has offered invaluable insights about the specific points of failure, which were never what I anticipated.
2. Hardcoded Configurations for Simplicity
Configurations are hardcoded into the application code:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
There are no configuration
