Embracing the 3-Month Rule: A Strategic Approach to Unscalable Solutions in Tech Development

In the world of entrepreneurship and tech startups, the wisdom of Paul Graham resonates deeply: “Do things that don’t scale.” Yet, how can we translate this vital advice into actionable steps, particularly when it comes to coding? After eight months of developing my AI podcast platform, I’ve established a straightforward framework: any unscalable hack is given a lifespan of three months. By the end of that period, the idea must either justify its existence and transition into a more robust solution or be put to rest.

As engineers, we often find ourselves wired to create scalable systems from the outset. We gravitate toward design patterns, microservices, and distributed architectures, envisioning systems that can support millions of users. However, this is an approach typical of larger organizations rather than startups.

In the context of a startup, aiming for scalability right away can lead to unnecessary complexity and expenses. You’re essentially preparing for user growth that may never happen and addressing problems that don’t exist yet. My three-month rule encourages me to write straightforward, albeit imperfect, code that can be deployed and tested quickly, allowing me to understand what users genuinely need.

Current Unscalable Approaches and Their Strategic Value

1. Consolidated Operations on a Single VM

I run my entire stack—including the database, web server, background jobs, and Redis—on a single virtual machine costing just $40 a month. While this approach lacks redundancy and relies on manual backups, it’s yielded invaluable insights about resource requirements. In only two months, I have learned that my platform’s peak resource usage is merely 4GB of RAM. The intricate Kubernetes setup I nearly pursued would have been overkill, managing empty containers rather than meaningful load.

When issues arise (which they have, twice), I gain concrete data on what fails, often revealing surprises that would have been overlooked in a more complex setup.

2. Hardcoded Configuration Throughout the Codebase

In my codebase, configuration values are hardcoded rather than managed via external files or environment variables:

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

This seemingly unorthodox method brings its own set of advantages. I can quickly search for any configuration value across my entire codebase. With each change