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

In the world of startups, conventional wisdom often emphasizes the importance of scalable solutions. As Paul Graham famously stated, “Do things that don’t scale.” However, implementing this advice—especially from a technical standpoint—remains under-discussed. Over the past eight months of developing my AI podcast platform, I’ve established a practical framework that I call the “3-Month Rule,” which allows me to explore unscalable hacks with a defined expiration date.

The Essence of the 3-Month Rule

When working in a startup environment, the temptation to create robust, scalable architectures from the outset can be overwhelming. We’re often swayed by the allure of microservices, distributed systems, and complex design patterns intended to support millions of users. However, this big-company mindset can lead to costly procrastination by focusing on theoretical needs rather than immediate, practical user requirements. My three-month timeframe helps me focus on developing straightforward, albeit “imperfect,” code that is genuinely useful and educational.

Current Hacks Worth Mentioning

Here are a few of the unconventional practices I’ve adopted, confounding conventional wisdom but yielding significant insights:

1. Consolidating Resources on One Virtual Machine

I’ve chosen to run my entire infrastructure—database, web server, background jobs, and caching—on a single low-cost virtual machine. While this setup has zero redundancy and relies on manual backups, it has provided invaluable clarity regarding my resource needs. In just two months, I’ve learned that my platform, which I assumed required a hefty infrastructure, actually peaks at a mere 4GB of RAM. The complex Kubernetes configuration I nearly devised would have been a misallocation of resources, maintaining empty containers.

When system crashes occur (and they have, twice), I gain firsthand insights into what genuinely fails—often surprising me.

2. Hardcoded Configurations for Simplicity

Instead of using config files or environment variables, I’ve opted for hardcoded constants throughout my codebase. This means any configuration change requires a redeployment, but it also allows me to swiftly track changes and ensures that each adjustment undergoes a self-review process. Over three months, I’ve amended these values only three times, saving me a substantial amount of engineering effort.

3. Utilizing SQLite in Production

I’ve taken the unconventional route of employing SQLite for a multi-user application. Given that my