Embracing the 3-Month Rule: A Practical Approach to Unscalable Solutions
In the entrepreneurial world of startups, particularly in the tech sphere, we often hear the wisdom of Paul Graham asking founders to “do things that don’t scale.” However, the challenge arises when attempting to make this philosophy actionable, especially within the realm of coding.
After spending eight months developing my AI podcast platform, I stumbled upon a framework that has fundamentally changed the way I approach unscalable hacks: each hack has a lifespan of three months. At the end of this period, I assess its effectiveness to determine whether it deserves a proper build-out or should be phased out entirely.
The Reality of startup Engineering
As engineers, we’re trained to focus on scalability from the outset. We get caught up in designing intricate systems like microservices and distributed architectures, all meant to handle vast user bases. Yet, in a startup setting, this may turn into an exercise in expensive procrastination. Too often, we find ourselves optimizing for hypothetical users and challenges that may never arise. My three-month rule compels me to prioritize straightforward, albeit “inelegant,” code that actually gets deployed. This process has been invaluable in helping me understand user needs more clearly.
My Selected Infrastructure Strategies and Their Merits
1. Consolidating Everything on One Virtual Machine
My entire infrastructure—from the database to the web server—is hosted on a single $40/month virtual machine. Sure, there’s no redundancy and I rely on manual backups, which might seem reckless. However, this approach has provided me with insights about my resource needs in just two months—insights that any lengthy capacity planning document would have failed to deliver. For instance, I discovered that my “AI-heavy” platform only requires 4GB of RAM, rendering an elaborate Kubernetes setup unnecessary.
Interestingly, when the system crashes (which has happened twice), I gain actual data on the points of failure, which often surprises me.
2. Simplified Configuration Management
Instead of cluttering my codebase with configuration files or environment variables, I use hardcoded constants:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
Every change involves redeploying, but the benefits are significant. The ability to quickly search for any configuration value and track changes through Git history far outweighs the
