Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Solutions in Tech

In the world of startups and software development, there’s a well-known piece of advice from Paul Graham: “Do things that don’t scale.” Yet, the conversation often skirts around how to actually apply this principle in coding practices.

After dedicating eight months to creating my AI podcast platform, I’ve developed a straightforward framework that I like to call the “3-Month Rule.” This guideline stipulates that any unscalable solution I’ve implemented has a lifespan of three months. Within that time frame, it must either demonstrate its value and transition into a more robust implementation or be discarded.

As engineers, we naturally gravitate toward establishing scalable solutions from the outset. We become engrossed in employing design patterns, microservices, and distributed systems—architectural marvels capable of supporting millions of users. However, this line of thinking typically aligns with larger corporations. In a startup setting, optimized code often leads to unnecessary expenses and delays, as it targets hypothetical users and addresses problems that may never arise.

This is where the 3-Month Rule proves beneficial; it encourages me to create simple, straightforward (even imperfect) code that can be deployed quickly. This hands-on approach provides invaluable insights into the actual needs of users.

Current Infrastructure Experiments: Unconventional Yet Insightful

1. Consolidated Operations on a Single Virtual Machine

I run everything—from the database to the web server and background processes—on a single $40-per-month virtual machine. While this setup lacks redundancy and relies on manual backups, the benefits have been profound. Within just two months, I gained a clearer understanding of my resource requirements than any planning document could offer. My initially anticipated database setup, involving Kubernetes, would have led to managing idle containers instead of focusing on effective user needs.

When the system encounters failures (which it has a couple of times), I receive specific insights into what truly fails. Not surprisingly, the issues often differ from my initial assumptions.

2. Hardcoded Configurations Across the Board

Instead of relying on configuration files or environment variables, I use constants directly in my code:

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

While this may seem primitive, it allows me to quickly search for and track any configuration