Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Solutions

In the world of startups, it’s common to hear the mantra from Paul Graham: “Do things that don’t scale.” While this advice is frequently cited, the actual implementation—especially in coding—often goes unexplored. After dedicating eight months to building my AI podcast platform, I’ve adopted a straightforward framework: every unscalable approach receives a trial period of three months. At the conclusion of this timeframe, the method must either demonstrate its value and evolve into a robust system or be discarded.

As engineers, we’re often wired to prioritize scalability. Our training emphasizes the development of architectural patterns like microservices and distributed systems that are equipped to handle millions of users seamlessly. Yet, this mindset can prove counterproductive in a startup environment, where anticipating scalability might just lead to unnecessary complexity and delayed progress.

The 3-Month Rule in Action

This guiding principle compels me to utilize straightforward, even “imperfect,” code that is shipped quickly. This approach not only accelerates the learning process but also reveals the genuine needs of users. Here’s a look at some unconventional strategies I’m using and the insights they’ve provided:

1. Consolidation on a Single VM

I run my database, web server, background jobs, and caching solution all on a single $40/month virtual machine. While this setup lacks redundancy and relies on manual backups, it has been enlightening. In just two months, I’ve learned about my platform’s actual resource demands—turns out, my supposed “AI-heavy” application only uses 4GB of RAM at peak. The complex Kubernetes architecture I nearly implemented would have had me managing unnecessary empty containers.

When the system crashes—as it has a couple of times—I gain valuable insights into real failure points, which are often surprising.

2. Hardcoded Configuration

Instead of employing configuration files or environment variables, I’ve hardcoded essential values like pricing tiers and user limits within my code. While this may seem cumbersome, it actually simplifies tracking and makes quick changes easy to implement. Each adjustment necessitates a redeployment, but in three months, I’ve altered these values merely three times—saving me a significant amount of engineering hours.

3. SQLite in a Multi-User Environment

Surprising as it may sound, I’m utilizing SQLite for my web application. With a database size of just 47MB, I’ve managed to support