Embracing the Three-Month Rule: A Pragmatic Approach to Building Scalable Code

In the startup landscape, the adage “do things that don’t scale,” as famously advised by Paul Graham, often seems easier said than done—especially when it comes to coding. After eight months of developing my AI podcast platform, I’ve crafted a straightforward framework that keeps me focused: every unscalable solution is given a mere three months to prove its merit. If it doesn’t demonstrate its usefulness by then, it’s scrapped.

As engineers, we often feel pressured to create scalable solutions from the get-go, delving into intricate architectures such as microservices and distributed systems meant to accommodate millions of users. However, this kind of thinking can hinder innovation in a startup setting, where investments in scaling often equate to procrastination. My three-month rule compels me to produce simple, efficient code that delivers results, allowing me to better understand the true needs of my users.

Current Simplifications: Why They Work

Here are a few of the unconventional strategies I currently employ and the insights they offer:

1. Consolidation on a Single VM

I host everything—from the database to the web server—on a singular $40/month Virtual Machine (VM). Yes, it lacks redundancy and requires manual backups, but this setup has provided me with invaluable insights into my resource utilization over two months. Monitoring my platform, which typically peaks at 4GB of RAM, taught me that the complex Kubernetes architecture I considered would have involved managing idle containers.

When the system fails—something that has happened twice—I gain crucial insights into actual failure points, and they’re rarely what I anticipated.

2. Hardcoded Configurations

Instead of relying on configuration files or environment variables, I utilize hardcoded constants throughout my code:

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

The power of this approach lies in its simplicity: I can easily search my entire codebase for any configuration value in moments. Each price adjustment is tracked via Git history, requiring minimal redeployment time compared to the weeks it would have taken to develop a configuration service.

3. SQLite for Production Use

Yes, I am using SQLite for my multi-user web application. This compact database, totaling only 47MB, efficiently manages up to 50 concurrent users.