Implementing the 3-Month Rule: A Practical Approach for Startups

In the world of startups, where rapid iteration and learning are paramount, the well-known advice from Paul Graham to “do things that don’t scale” often goes unexamined. As a developer who has spent the last eight months building an AI-driven podcast platform, I’ve encountered this wisdom firsthand. Thus, I crafted a straightforward yet effective framework: any unscalable hack I implement gets a trial period of just three months. After this period, it either demonstrates its value and gets refined into a scalable solution, or it’s discarded.

The push for scalability is deeply ingrained in the engineering mindset, leading many to invest time in elaborate architectures from the get-go. However, in a startup environment, often this focus on scalability translates to procrastination. We find ourselves optimizing for hypothetical users and unforeseen challenges. My 3-month rule compels me to write straightforward, albeit imperfect, code that can be launched quickly, allowing me to truly understand the needs of my users.

My Unconventional Hack: Infrastructure Insights

Here are some of the strategies I’ve employed in my project and the rationale behind them:

1. Consolidated Architecture on a Single VM

I run my entire platform — web server, database, background jobs, and cache — on a single $40/month virtual machine. While it lacks redundancy and I perform manual backups, the insights gained in months have been invaluable. Within two months, I’ve identified that my “AI-heavy” platform effectively operates on just 4GB of RAM, negating the need for a complex Kubernetes setup I almost initiated. Additionally, when crashes occur (yes, there have been a couple), I receive genuine feedback on what fails — and it’s often surprising.

2. Hardcoded Configuration for Simplicity

Instead of relying on external configuration files or environment variables, I’ve opted for hardcoded constants throughout my codebase. This means any changes require redeployment, yet the speed at which I can search for configuration values more than compensates for the simplicity lost. Each price modification is easily tracked in Git, and such an approach saves me immense amounts of engineering time, as I’ve only adjusted these values a few times over three months.

3. SQLite as My Primary Database

I know what you’re thinking: using SQLite for a multi-user application is risky. Nevertheless, my database is a mere 47MB and seamlessly accommodates 50 concurrent users