Embracing the 3-Month Rule: A Strategic Approach to Non-Scalable Coding

In the world of tech startups, the sound advice of Paul Graham—”Do things that don’t scale”—often rings true. However, what remains under-discussed is how to practically apply this principle in software development. After dedicating eight months to building my AI podcast platform, I’ve adopted a straightforward framework: every unscalable solution I implement has a lifespan of three months. Following this period, it must either demonstrate its value and get the necessary overhaul—or it will be discarded.

As engineers, we are typically trained to prioritize scalable solutions right from the outset. We become proficient in utilizing design patterns, building microservices, and creating distributed systems—all geared towards supporting millions of users. Yet, this mindset often belongs to larger organizations, and can lead to unnecessary complexity for startups.

In the early stages of a startup, creating scalable code can be equivalent to delaying crucial decisions. We often find ourselves optimizing for users who aren’t yet present, addressing hypothetical issues, and missing opportunities to learn from real user interactions. My three-month rule compels me to create direct, albeit imperfect, code that allows me to ship quickly and gain insight into actual user needs.

Current Infrastructure Hacks: Lessons Learned

Here are some of the unconventional practices I’m currently employing and why I believe they are beneficial:

1. Consolidation on a Single VM

I run my database, web server, background jobs, and caching on one $40/month virtual machine, sacrificing redundancy and depending on manual backups. This approach has proven enlightening; in the past two months, I’ve gained a clearer understanding of my resource requirements than any capacity planning document could offer. The platform, which I anticipated to be resource-intensive, only peaks at 4GB of RAM. Had I gone ahead with a complex Kubernetes setup, I would have spent time managing resources that weren’t being utilized.

When the system crashes—an event that has occurred twice—I receive genuine insights into what fails, and it consistently surprises me.

2. Simplified Hardcoded Configuration

Instead of using configuration files or environment variables, I’ve opted for constants throughout my code:

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

The straightforward nature of this setup allows me to quickly search