The Three-Month Rule: A Pragmatic Approach to Non-Scalable Solutions

In the landscape of startup development, the concept of doing things that don’t scale, famously championed by Paul Graham, is often cited but less frequently explored in the context of coding practices. After dedicating eight months to building my AI podcast platform, I’ve established a straightforward principle: any unscalable workaround is given a three-month trial period. At the end of this timeframe, the option must either demonstrate significant value to warrant further development or be phased out entirely.

As software engineers, we are frequently taught to create scalable solutions from the outset. The allure of sophisticated design patterns, microservices, and distributed systems can have us focusing on grand architectures prepared for millions of users. However, in a startup environment, this often leads to what I believe is ‘expensive procrastination’—devoting resources to scenarios that may never materialize. My three-month rule promotes the creation of straightforward, even ‘imperfect’ code that enables an authentic understanding of user needs.

Key Infrastructure Innovations I’ve Adopted

1. Consolidating Everything on a Single VM

Currently, my database, web server, background processes, and caching all operate on a single virtual machine costing $40 per month. This design lacks redundancy and relies on manual backups.

Why is this approach beneficial? Over the past two months, I’ve gained invaluable insights into my actual resource requirements—far beyond what traditional capacity planning could provide. For instance, I’ve determined that my ‘AI-heavy’ platform typically requires only 4GB of RAM. The complex Kubernetes architecture I considered building would have merely led to managing idle containers, not solving real issues.

When I experience crashes (and yes, that’s happened twice), I gather critical data on failures. To my surprise, the reasons for these disruptions often differ from my expectations.

2. Using Hardcoded Configuration

Consider this:

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

I have no configuration files or environment variables—just constants embedded throughout the code. This means any adjustments necessitate a redeployment.

Here’s the brilliance: I can search through my entire codebase for any configuration parameter in seconds. Each pricing alteration gets documented in my Git history, and changes get reviewed at a glance—even if that review is just