Embracing the 3-Month Rule: A Framework for Agile Development in Startups

The tech world often reverberates with the advice from Paul Graham urging us to “do things that don’t scale.” Yet, the discussion rarely delves into the practical implementation of this principle, especially in coding. Over the past eight months, while developing my AI podcast platform, I’ve established a straightforward yet effective framework: every unscalable solution I implement gets a three-month trial period. After this time, it either demonstrates its worth and is built out properly, or it is discarded.

As engineers, we are conditioned to focus on scalable solutions right from the start, crafting intricate design patterns, deploying microservices, and setting up distributed systems—all of which are optimized for handling potentially millions of users. However, this mindset often represents a larger corporate mentality that can stifle agility in startup environments.

Here, the pursuit of scalable code may simply serve as an expensive form of procrastination. You’re preemptively preparing for challenges that may never materialize, while overlooking immediate user needs. My three-month rule compels me to produce straightforward, even “imperfect,” code that delivers functional output, allowing me to gain insights into the genuine requirements of my users.

Exploring My Current Tactical Implementations

1. Consolidated Resources on a Single VM

To keep things streamlined, I host everything—from the database to the web server, and background jobs—on a single $40/month Virtual Machine (VM). There is no redundancy, and I manage backups manually.

Why is this a strategic move? In just two months, I’ve gathered invaluable data on actual resource consumption that’s far more informative than any theoretical capacity planning document. I’ve discovered that my platform, which I initially deemed “AI-heavy,” peaks at a modest 4GB of RAM. The elaborate Kubernetes architecture I almost initiated would have meant managing idle containers.

When my VM experiences crashes (which has occurred a couple of times), I receive clear insights into the real issues at hand—often not what I anticipated.

2. Hardcoded Constants for Configuration Management

Instead of utilizing config files or environment variables, I’ve opted for hardcoded constants throughout my codebase. For instance:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"

This approach might seem archaic, but