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

In the world of technology startups, there’s a well-known mantra popularized by Paul Graham: “Do things that don’t scale.” However, the conversation rarely shifts to the practical application of this advice, especially in the realm of coding.

Having spent the last eight months developing my AI podcast platform, I’ve devised a straightforward approach: every unscalable hack I implement gets a trial period of three months. After that duration, it’s either validated through real-world use and developed into a robust solution, or it’s phased out entirely.

Why the 3-Month Rule Works

As engineers, we’re often conditioned to design scalable solutions from the outset—complete with design patterns and microservices architecture intended to cater to millions of users. While this methodology is essential for large companies, it can become a luxury for startups. In these early stages, investing time and resources into scalability can turn into an expensive form of procrastination, focusing on hypothetical users and problems yet to emerge. My 3-month rule compels me to create straightforward, even “imperfect,” code that ships quickly and reveals what users genuinely require.

Key Unscalable Strategies I’m Implementing

Here are some of the unconventional strategies I’ve adopted during this phase, and why I believe they are not just valid but also strategic:

1. Consolidated Infrastructure on One VM

Everything—from the database to the web server—resides on a single $40/month virtual machine. While lacking redundancy and relying on manual backups, this setup has illuminated my actual resource needs far more effectively than any theoretical capacity planning could. I’ve discovered that my platform only needs about 4GB of RAM, saving me from the complexities of a Kubernetes architecture that would have handled mostly empty containers. Each crash has provided valuable insights into the system’s weaknesses, most of which were unexpected.

2. Simplified Hardcoded Configurations

With constants sprinkled throughout my code rather than in configuration files or environment variables, modifications require a simple redeploy. This might seem like a retrograde step, but it allows me to track all changes in version control and easily find any configuration value across the codebase. The time saved—less than 15 minutes for a few changes—far outweighs the effort of creating a full-fledged configuration service.

3. Using SQLite in Production

Yes, you read that right—SQLite powers my multi-user web app with a