Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Solutions in Tech
When it comes to startup culture, few pieces of advice resonate quite like Paul Graham’s mantra: “Do things that don’t scale.” However, the specifics of how to apply this principle in the realm of software development often go unexplored.
Having spent the last eight months constructing my AI podcast platform, I’ve cultivated a straightforward framework to manage unscalable tactics: any temporary solution implemented for the project is granted a lifespan of three months. After this trial period, it either validates its worth through performance and user feedback, or it is phased out.
Rethinking Scalability in Development
As engineers, we often find ourselves gravitating towards scalable solutions from the outset, focusing on sophisticated architectures like microservices and distributed systems meant to cater to millions of users. But here’s the catch: in the early stages of a startup, pursuing scalability can turn into an expensive form of procrastination. We’re often preemptively solving issues for hypothetical future users while neglecting the immediate needs of our current audience. By adhering to my self-imposed 3-month rule, I prioritize straightforward, albeit “messy,” code that prompts real user interactions, ultimately clarifying what features are genuinely required.
The Current Hacks Guiding My Development
1. Unified VM Infrastructure
I operate the entire application—database, web server, background jobs, and caching—on a single $40 per month virtual machine. While this approach lacks redundancy and relies on manual backups, it has provided invaluable insights into my resource demands. Over just two months, I’ve realized that my platform’s maximum requirements peak at 4GB of RAM. The complex Kubernetes architecture I nearly implemented would have been unnecessarily managing idle containers. When the system crashes—twice, so far—I gain concrete knowledge about actual failure points, which frequently defy my initial assumptions.
2. Hardcoded Configuration Values
In my code, configuration constants like:
python
PRICE_TIER_1 = 9.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
are sprinkled throughout the files, eliminating the hassle of config files or environment variables. Admittedly, changing these values does necessitate a redeployment, but therein lies the hidden advantage: I can search through my entire codebase in seconds. Each adjustment is tracked meticulously in git history, and I review every change myself—even if it’s only
