Embracing the Unscalable: The 3-Month Rule for Startups

In the world of entrepreneurship, a well-known mantra often echoes: “Do things that don’t scale.” This sage advice, as articulated by Paul Graham, is pivotal yet somewhat elusive, particularly when it comes to applying it in the realm of software development.

After eight months of developing my AI podcasting platform, I’ve devised a straightforward strategy: every unscalable approach I implement is given a lifespan of exactly three months. After this period, I assess whether it has proven its value and deserves further investment or if it should be discontinued.

As developers, we are frequently trained to focus on “scalable” solutions from the outset—creating elaborate architectures with microservices and distributed systems designed to manage millions of concurrent users. However, such large-scale thinking often misses the mark in a startup environment, where creating scalable solutions can lead to costly delays, focusing on hypothetical users and issues that may never arise.

My 3-month rule emphasizes the importance of crafting straightforward, albeit imperfect, code that is capable of being deployed. This approach enables me to understand user requirements more effectively.

My Current Infrastructure Strategies and Their Surprising Benefits

1. Consolidating on a Single Virtual Machine

I run my entire application—including the database, web server, background tasks, and caching—on a single $40/month virtual machine. This setup lacks redundancy and involves manually backing up to my local machine.

You might wonder why this is a wise choice instead of a reckless one. The reality is that I’ve gained invaluable insights regarding my resource requirements in just two months, insights that would have otherwise eluded a formal capacity planning document. My application, which I initially anticipated would demand significant resources, only peaks at 4GB of RAM. The complex Kubernetes architecture I considered would have simply involved managing idle containers.

Whenever the system crashes—an experience I’ve already encountered twice—I receive genuine feedback on the real causes, often surprising those who assumed otherwise.

2. Hardcoded Configuration Parameters

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

Rather than utilizing configuration files or environmental variables, I scatter constants throughout my codebase. Modifying any parameter necessitates redeployment.

What’s the upside? The efficiency of being able to search my entire codebase for configuration