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

In the startup ecosystem, the notion of embracing unscalable strategies is frequently extolled, as highlighted by Paul Graham’s popular adage: “Do things that don’t scale.” However, while this philosophy is widely recognized, the execution of such strategies from a technical standpoint often remains under-discussed.

As I venture into developing my AI podcast platform—now eight months into the journey—I’ve established a straightforward framework: every non-scalable hack I employ is given a lifespan of precisely three months. After this period, it either proves its worth and is refined into a proper solution or gets scrapped entirely.

The reality for engineers, especially those trained in larger organizations, is a tendency to architect scalable solutions right from the outset. This involves implementing complex design patterns, microservices, and distributed systems—all aimed at accommodating potentially millions of users. Yet, in the context of a startup, this mindset can lead to costly delays, as one often optimizes for theoretical users while overlooking the pressing needs of current ones. My 3-month rule compels me to write straightforward, even “imperfect,” code that can be deployed swiftly, allowing me to glean insights into what users genuinely require.

Smart Infrastructure Hacks in Action

Here’s a look at some of my current technical strategies that, at first glance, might seem reckless but are serving me well:

1. Unified Virtual Machine Deployment

Currently, everything—my database, web server, background jobs, and Redis—operates on a single $40/month virtual machine. This setup lacks redundancy and relies on manual backups.

Why is this working? Within the past two months, I’ve acquired more practical knowledge about my resource needs than I ever could from abstract capacity planning. I’ve found that my AI-driven platform typically requires about 4GB of RAM. The elaborate Kubernetes architecture I had contemplated would’ve only managed idle containers.

When the system crashes (which has occurred twice thus far), it reveals valuable data on what precisely fails—often surprising me.

2. Hardcoded Configurations

Instead of managing configuration files and environment variables, I use constants scattered throughout my codebase, like:

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

Adjusting any value necessitates a redeployment, making