Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Solutions in Tech
In the startup ecology, advice often circles around the well-known mantra from Paul Graham: “Do things that don’t scale.” While this wisdom is widely recognized, the nuts and bolts of applying it—particularly in the realm of coding—are less frequently explored. Over the past eight months, as I’ve been developing my AI podcast platform, I’ve devised a straightforward yet effective framework: every unscalable approach is granted a lifespan of three months. Afterward, it either proves its utility and transitions to a more robust implementation, or it gets eliminated.
It’s common for engineers to focus on creating solutions that can handle massive user bases from the outset. We’re trained to think in terms of sophisticated architectures—design patterns, microservices, and distributed systems—yet this mindset can lead startups down a path of unnecessary complexity. The reality is that building scalable solutions too early can often translate into costly procrastination. Instead of anticipating the needs of future users, my 3-month rule compels me to produce straightforward, and admittedly imperfect, code that actually gets deployed, allowing me to better understand the needs of my users.
Current Infrastructure Strategies: A Pragmatic View
1. Consolidated Operations on a Single VM
I run my database, web server, background jobs, and Redis on an unadorned $40/month virtual machine (VM). There’s no redundancy, and I perform manual backups to my local system. Here’s the brilliance of this approach: in just two months, I’ve gained invaluable insights into my resource requirements—insights that would have taken an exhaustive capacity planning document to uncover. My initial heavy AI platform only needed 4GB of RAM, which means that the complex Kubernetes setup I almost implemented would have been managing idle containers.
Whenever the system crashes (which has happened twice so far), I receive concrete data about the points of failure—surprisingly, these are rarely what I had anticipated.
2. Hardcoded Configuration Across the Board
plaintext
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
I utilize straightforward constants as opposed to configuration files or environment variables. Each change necessitates a redeployment. The silver lining? I can quickly search my codebase for any configuration values
