Embracing Unscalable Solutions: The 3-Month Rule for Startups

In the world of startups, there’s a well-known piece of advice from Paul Graham: “Do things that don’t scale.” While many are familiar with this notion, the real challenge lies in how to apply it effectively within the realm of coding and development. After eight months of building my AI podcast platform, I’ve developed a straightforward framework: any unscalable hacks I implement are given a lifespan of three months. After that period, they must either prove their worth and be transformed into robust solutions, or they are discarded.

As engineers, we often focus on creating scalable solutions from day one. We immerse ourselves in design patterns, microservices, and elaborate architectures designed to accommodate millions of users. However, this mindset is typical of larger companies. In a startup environment, writing scalable code can be nothing more than procrastination—optimizing for users who haven’t yet materialized, addressing issues that may never arise. My three-month rule compels me to produce straightforward, if imperfect, code that gets deployed and reveals what users genuinely need.

Current Infrastructure Hacks: Simplifying for Clarity

1. All-in-One Virtual Machine

I’m running my entire stack—database, web server, background jobs, and caching—on a single $40/month virtual machine. There’s no redundancy and my backups are manual, saved locally.

This setup may appear reckless, but it has been incredibly enlightening. Within just two months, I’ve gained insights into my actual resource requirements that traditional capacity planning could never offer. Surprisingly, my AI-focused platform peaks at 4GB of RAM. The complex Kubernetes environment I nearly built would have meant managing unused containers.

When the system crashes (which has happened twice), I gather valuable data on what failed. Spoiler alert: it’s never what I anticipated.

2. Hardcoded Configuration

Instead of employing configuration files and environment variables, I’ve chosen constants directly in the codebase:

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

While this might seem naïve, it has an unexpected advantage: I can perform quick searches across my entire codebase for any configuration value. Every price adjustment is logged in Git history, and any configuration change undergoes a code review—albeit one I conduct myself