Embracing the 3-Month Rule: A Practical Approach to Building What Doesn’t Scale

Ever heard the advice from tech visionary Paul Graham to “do things that don’t scale”? While many of us nod in agreement, implementing this principle in the world of coding can seem elusive. After dedicating eight months to developing my AI podcast platform, I’ve crafted a straightforward framework: any unscalable hack I introduce is given a trial period of three months. At the end of this timeline, each hack must either prove its worth by evolving into a more sustainable solution or be discarded.

As engineers, we often gravitate towards creating “scalable” solutions right from the start. We’re trained to think in terms of microservices, distributed systems, and complex architectures adept at managing millions of users. However, such thinking often belongs to established enterprises, not startups. In many cases, optimizing for users who don’t yet exist can lead to costly delays—what I like to call “expensive procrastination.” My 3-month rule encourages me to craft straightforward, albeit imperfect, code that can be deployed quickly and offers valuable insights into what my users genuinely need.

Current Non-Scalable Strategies and Their Strengths

Here’s a look at my current infrastructure choices, crafted with a different mindset:

1. Simplifying with One VM

All my essential services—database, web server, background jobs, and Redis—are consolidated on a single $40/month virtual machine. With this setup, I maintain zero redundancy and perform manual backups to my local system.

Why is this approach effective? In just two months, I’ve gained clearer insights into my resource needs than any theoretical capacity planning document could provide. The platform, which I anticipated to be resource-intensive, only requires a peak of 4GB RAM. The elaborate Kubernetes orchestration I nearly implemented would have meant managing unused containers. Each crash (which has happened twice) has revealed unexpected points of failure, providing invaluable real-time data.

2. Hardcoded Configurations

For configurations, I avoid complex setups entirely. Constants are strewn across various files like so:

python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"

While this may seem simplistic, it allows for rapid changes and easy tracking in my version control system. Each of the three adjustments made over the past three