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

In the world of startups and agile development, there’s often a mantra popularized by Paul Graham: “Do things that don’t scale.” While many understand the concept, the execution—especially in the realm of coding—remains an under-discussed topic.

After eight months of developing my AI podcast platform, I’ve crafted a straightforward yet effective methodology: every unscalable solution I implement gets a three-month trial period. At the end of this timeframe, either the approach will prove its worth and be upgraded, or it will be discarded.

As engineers, we are often conditioned to focus on scalable solutions from the outset. We get caught up in design patterns, microservices, and distributed systems—architectures designed to accommodate millions of users. However, this perspective is often more suited to established companies rather than startups.

In the early stages of a startup, pursuing scalability can merely lead to costly delays. We might be optimizing for hypothetical users or addressing challenges that don’t yet exist. By adhering to my three-month rule, I’m compelled to write straightforward, perhaps imperfect, code that actually delivers results and helps me understand user needs more effectively.

Current Infrastructure Hacks: A Smart Approach

Here’s a look at my current infrastructure strategies and the reasoning behind them:

1. Consolidated on a Single VM

I run my database, web server, background jobs, and caching system all on a single virtual machine costing $40 a month. There’s no redundancy and manual backups to my local system.

Why is this a smart choice? In just two months, I’ve gained a clearer understanding of my resource requirements than any capacity planning document could provide. I’ve determined that my “AI-heavy” platform only peaks at 4GB of RAM. The more complex Kubernetes setup I considered would have involved managing idle containers.

Each time my VM crashes (which has happened twice), I gather valuable real-world data about what actually fails—often unexpected insights that inform my decisions.

2. Hardcoded Configuration

My configuration is straightforwardly hardcoded within the code itself:

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

This means there are no external configuration files or environment variables; constants are embedded throughout the codebase.

The benefit? I can quickly search