Embracing Imperfection: The 3-Month Rule for Building an AI Podcast Platform

In the entrepreneurial world, there’s a classic piece of advice from Paul Graham: “Do things that don’t scale.” While many acknowledge this principle, the conversation frequently overlooks how to effectively incorporate it, especially in coding. Drawing from my experiences over the past eight months building an AI podcast platform, I’ve developed a method I like to call the 3-Month Rule. This approach mandates that any unscalable solution is permitted to exist for only three months. After this period, it must either demonstrate its value and be refined into a more robust solution, or it must be discarded.

As software engineers, we often feel compelled to create solutions that emphasize scalability from the outset. We focus on best practices like design patterns, microservices, and distributed systems—an architecture intended for handling millions of users. However, in the early stages of a startup, striving for scalable solutions can turn into an exercise in costly procrastination. With my 3-month rule, I force myself to craft straightforward, albeit imperfect, code that enables me to better understand the real needs of my users.

Current Infrastructure Hacks and Their Strategic Value

1. Operating on a Single VM

Currently, my entire infrastructure—database, web server, background jobs, and caching—runs on a single $40/month virtual machine. This setup lacks redundancy and relies on manual backups to my local machine.

Why is this approach savvy instead of reckless? Within two months, I gained far more insight into my actual resource requirements than any capacity planning document could provide. My so-called “AI-heavy” platform only peaks at 4GB of RAM. The complex Kubernetes framework I almost implemented would have merely involved managing a bunch of idle containers. Not to mention, every time I encountered a crash (which has happened twice), I gleaned invaluable data about the real points of failure—none of which aligned with my initial expectations.

2. Hardcoded Configurations

Instead of using configuration files or environment variables, I’ve opted to hardcode crucial values throughout my codebase. Elements like pricing, user limits, and selected AI models are constants sprinkled throughout various files, requiring a redeploy for any adjustments.

The beauty of this decision? It allows for rapid searching across the entire codebase to trace configuration values, with each change recorded in git history and reviewed—albeit by just myself. Building a configuration service would have taken a