The 3-Month Rule: A Pragmatic Approach to Unscalable Coding Practices

In the entrepreneurial world, we often hear the celebrated advice from Paul Graham: “Do things that don’t scale.” However, the practical application of this philosophy in software development tends to remain an area of ambiguity. After spending eight months working on my AI podcast platform, I’ve devised a straightforward framework: every unscalable approach I employ gets a lifespan of precisely three months. At the end of that period, the method either proves its worth and receives the proper architecture it deserves, or it gets scrapped.

The reality is that as developers, we are conditioned to create “scalable” solutions right off the bat. We often gravitate towards intricate patterns, microservices, and distributed systems—all designed to handle massive user bases. Yet, this perspective is more suited for larger companies.

In the startup ecosystem, building scalable code can often lead to expensive delays, as it focuses on users that do not yet exist and on problems that may never arise. By adhering to my three-month rule, I am compelled to write simpler, more direct code that may not be “beautiful” but is functional and informative. This method helps me gain critical insights into the actual needs of my users.

Here are Some of My Current Infrastructure Strategies and Why They Work:

1. Consolidated Resources on a Single VM

I run my database, web server, background jobs, and Redis on a single $40/month virtual machine, without any redundancy. Though backup processes are manual, this decision has proven to be a wise one. In just two months, I’ve gained invaluable insights into my true resource demands, significantly more than any capacity planning document could have provided. For instance, it turns out that my platform peaks at about 4GB of RAM—an elaborate Kubernetes deployment would have been wasted managing idle containers.

When the server crashes (which has happened a couple of times), I receive genuine data about what fails, and interestingly, it’s never what I anticipated.

2. Hardcoded Configuration

I’ve opted for hardcoded constants throughout my codebase:

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

No configuration files or environment variables—just immediate values scattered around. While changing any value necessitates a redeployment, I can quickly search