Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Coding in Startups

In the world of startups, where agility and rapid iteration are paramount, we often hear seasoned entrepreneurs echo the wisdom of Paul Graham: “Do things that don’t scale.” Yet, the challenge lies in how to effectively apply this philosophy in our technical endeavors. After eight months of developing my AI podcast platform, I’ve crafted a straightforward strategy: any unscalable solution gets a lifespan of just three months. This timeframe serves as a litmus test to evaluate its true value—either it evolves into a robust solution or is retired.

Many engineers, myself included, have been conditioned to prioritize scalable systems from the outset. We easily get drawn into the allure of elegant design patterns, microservices, and distributed systems capable of handling millions of users. This perspective, however, often belongs to larger organizations rather than scrappy startups. In a startup environment, focusing on scalable architecture too soon can lead to costly delays as we prepare for problems that may never arise.

The 3-Month Experimentation Framework

By adhering to my 3-month rule, I deliberately opt for straightforward, sometimes “messy,” code that allows me to quickly ship features and discover real user needs. Here are some current infrastructural hacks I’ve implemented, each with its own merit:

1. Single-VM Setup

I run my entire application stack—including the database, web server, background jobs, and Redis—on one $40/month virtual machine, without redundancy. Although this configuration seems risky, it has provided invaluable insight regarding my actual resource requirements. I’ve consistently observed that my “AI-heavy” platform only needs 4GB of RAM at peak times. The complex Kubernetes setup I nearly pursued would have added unnecessary complexity, managing resources that I wasn’t using.

2. Hardcoded Configuration

Instead of using configuration files or environment variables, I have constants designated throughout my code. For example:

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

While this approach may seem archaic, it offers the advantage of rapid visibility into configuration changes. If I need to adjust a value, I redeploy—an operation that takes mere minutes compared to developing an entire configuration service.

3. Utilizing SQLite in Production

Yes, I opted for SQLite for