Embracing the 3-Month Rule: A Practical Approach to Unscalable Development
The tech community often hears the advice from Paul Graham to “do things that don’t scale.” However, the practical application of this principle, especially in the realm of coding, is seldom discussed. As someone who has spent the last eight months developing an AI podcast platform, I’ve discovered a straightforward yet effective framework: every unscalable approach I try is given a lifespan of just three months. Within this time, it must either prove its worth and evolve into a fully-fledged solution, or it will be discarded.
As engineers, we often lean towards creating scalable solutions from the outset. We become enamored with sophisticated architectures like microservices and distributed systems, which are designed to accommodate potentially millions of users. While this forward-thinking mentality is essential in larger companies, at a startup, it may lead to premature optimization and wasted resources.
In my experience, scalable code can often turn into costly procrastination. When you design for non-existent users, you risk spending significant time on issues that have yet to arise. My three-month rule encourages me to embrace simpler, more direct code—code that might be perceived as “bad” but ultimately enables me to ship quickly and gather valuable insights about genuine user needs.
My Current Infrastructure Strategies: The Rational Behind My Choices
1. Consolidation on a Single VM
Currently, my entire infrastructure—from the database and web server to background jobs and Redis—operates on a single $40/month virtual machine. There’s no redundancy involved, and I perform manual backups to my local system.
Why is this a wise strategy? In just two months, I’ve gained more insight into my actual resource requirements than I would have from any formal capacity planning document. It turns out my platform’s demands peak at about 4GB of RAM. The elaborate Kubernetes setup I nearly implemented would have resulted in me managing idle containers.
Each time my server crashes (which has happened twice so far), I gain practical knowledge about the root causes of the failure, which are often surprising.
2. Hardcoded Configurations
In my code, I avoid using configuration files or environment variables; instead, I rely on hardcoded constants. For instance:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
Changing any of these values
