Embracing the 3-Month Rule: A Strategic Approach to Building an AI Podcast Platform

In the world of startups, where agility and swift changes are essential, the mantra of “doing things that don’t scale” often resonates. While this advice, popularized by tech visionary Paul Graham, is well-known, the practical implementation within the realm of software development remains less discussed.

Over the past eight months, as I’ve been dedicated to developing my AI podcast platform, I uncovered a straightforward yet effective strategy: I allow each unscalable solution a lifespan of three months. At the end of this period, the solution must either demonstrate its value and evolve into a robust component of my system or be discarded.

As engineers, we are conditioned to prioritize scalable solutions right from the outset. This often leads us to focus on sophisticated architectures—designed to support millions of users—before we even have a few. However, in the startup ecosystem, this advanced planning can be a form of procrastination, optimizing for users who might not even exist yet. The three-month rule encourages me to write simpler, more direct code that pushes me to ship quickly, allowing me to discover the actual needs of my users.

Current Infrastructure Hacks: Practicality Meets Innovation

1. Consolidated Infrastructure on a Single VM
I’ve chosen to host my entire platform—including the database, web server, background jobs, and caching—on a single virtual machine that costs just $40 a month. This setup lacks redundancy and relies on manual backups but offers invaluable insights. Within two months, I’ve gained a clearer understanding of my resource requirements than any complex capacity planning could provide. Surprisingly, my application peaks at just 4GB of RAM, debunking the need for an elaborate Kubernetes approach, which would have only managed idle containers. Each time my system crashes—a rarity—I receive genuine feedback about what components truly require my attention.

2. Simple Hardcoded Configurations
Instead of employing configuration files or environment variables, I utilize hardcoded constants throughout my codebase. Updating these values necessitates a complete redeployment, which may sound inconvenient. However, this method has proven its worth: I can quickly search for any configuration parameter and track changes through Git history with ease. Rebuilding a formal configuration service would consume a week of engineering time, while my approach has allowed for minimal changes over three months—amounting to a fraction of that time.

3. Running SQLite in Production