The 3-Month Rule: A Pragmatic Approach to Non-Scalable Coding

In the startup landscape, the prevailing wisdom often echoes the sentiments of thought leaders like Paul Graham, who advocates for “doing things that don’t scale.” Yet, seldom do we engage in discussions regarding the practical implementation of this principle within the realm of coding.

Over the past eight months, while developing my AI podcast platform, I’ve crafted a straightforward yet effective framework: any unscalable workaround is granted a life span of three months. Within this time frame, it must either justify its existence by demonstrating tangible value, or it will be discarded.

Traditionally, engineers are conditioned to prioritize scalable solutions from the outset. We often find ourselves immersed in sophisticated methodology, from design patterns to microservices and distributed systems—optimal architectures that can theoretically accommodate millions of users. However, such thinking can be a hindrance in the startup context, where scalable code is frequently a costly form of procrastination. We tend to prepare for users who aren’t even on the radar yet, addressing challenges that may never arise. By adhering to my three-month rule, I compel myself to produce straightforward, less refined code that can launch and provide genuine insights into user requirements.

My Current Simplified Infrastructure Hacks and Their Strategic Value

1. Unified Operations on a Single Virtual Machine

All essential components—including the database, web server, background jobs, and Redis—operate on a single $40/month VM. While this setup lacks redundancy and relies on manual backups to my local machine, it has proven to be a strategic move. Over two months, I have amassed invaluable knowledge regarding my actual resource requirements, far beyond what any capacity planning document could provide. Surprisingly, my so-called “AI-intensive” platform peaks at merely 4GB of RAM. The sophisticated Kubernetes setup I almost established would have merely been managing empty containers.

Each crash (and there have been a couple) offers real-time data about what truly fails—never exactly what I anticipated.

2. Hardcoded Configuration

In my code, configurations like PRICE_TIER_1 = 9.99 and MAX_USERS = 100 are hardcoded instead of nestled within configuration files or environment variables. While this might seem archaic, it allows me to swiftly locate any configuration value via searching my codebase. Each price adjustment is meticulously tracked in git history, and I can review configuration changes in my own pull requests. Creating a dedicated configuration