Embracing the 3-Month Rule: A Simplified Approach to Unscalable Coding

In the world of startups, the advice from thought leader Paul Graham resonates deeply: “Do things that don’t scale.” However, translating this wisdom into practical coding strategies often goes under-discussed. After eight months of developing my AI podcast platform, I’ve established a framework that prioritizes experimentation—one that allows unscalable hacks to thrive for a limited time before making definitive decisions about their future.

Breaking Away from Scalable Norms

As engineers, we are frequently trained to seek scalable solutions from the onset. We envision beautifully orchestrated structures involving design patterns, microservices, and distributed systems to accommodate potentially millions of users. Yet, in the startup realm, such scalability often results in costly delays. Many times, we find ourselves optimizing for imagined users and addressing problems that may never arise. By applying my 3-month rule, I am encouraged to create straightforward, even “imperfect,” code that is deployable and revealing about actual user needs.

My Ingenious Infrastructure Hacks

1. Unified Virtual Machine (VM) Usage

My entire tech stack runs on a single $40 per month VM that houses the database, web server, background jobs, and Redis. There’s no backup redundancy—manual backups go directly to my local machine.

Why is this a smart move? In just two months, I’ve garnered invaluable insights about my resource requirements that no planning document could provide. For instance, my “AI-centric” platform typically peaks at 4GB of RAM. The elaborate Kubernetes setup I was contemplating would have simply managed non-existent resources.

By experiencing system failures (which have happened twice), I’ve learned the real causes of breakdowns—often different from my initial assumptions.

2. Hardcoded Configurations

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

I’ve opted for hardcoded configuration values spread throughout the code rather than relying on separate config files or environment variables. If I need to change something, the deployment process is straightforward.

This approach affords me quick access to any configuration value via a simple grep command. All price adjustments are captured in the git history, and each update undergoes review—albeit by me. The time saved using this method—15 minutes for redeployment versus potentially 40 hours for