The Three-Month Rule: A Practical Approach to Building Scalable Solutions

In the tech world, advice from industry leaders often stands as guiding principles. One such recommendation from Paul Graham, co-founder of Y Combinator, is to “do things that don’t scale.” While this guidance is frequently echoed, the challenge lies in its execution, particularly in coding.

Over the past eight months while developing my AI podcast platform, I have adopted a unique methodology: I allow every unscalable solution or hack a lifespan of just three months. At the end of this period, each hack must demonstrate its value or be discarded.

The startup Mindset: Embracing Imperfection

As software engineers, we are typically trained to create scalable solutions from the outset—focusing on sophisticated design patterns and architecture intended to support millions of users. However, for startups, chasing scalability too early can often lead to unnecessary complications and delays. My three-month rule compels me to create straightforward, even “imperfect,” code that delivers functional results, providing critical insights into what users truly need.

My Ingenious Infrastructure Hacks

Here are some of the unorthodox but effective strategies I’ve implemented, each offering valuable learning opportunities:

1. Consolidation on a Single VM

All essential functions—database, web server, background jobs, and caching—are run on a single $40/month virtual machine without redundancy. This may seem reckless, but it has proven invaluable. Over the past two months, I’ve gained far more insight into actual resource requirements than any theoretical planning would provide. As it turns out, my “AI-heavy” platform needs peak at just 4GB of RAM. The complex Kubernetes environment I nearly implemented would have been managing unnecessary empty containers. When crashes occur (and they have), they reveal real weaknesses—surprisingly, not in the areas I had anticipated.

2. Hardcoded Configurations

Instead of employing configuration files or environment variables, I have opted for hardcoded constants in my source code. Changes require redeploying, but this approach has a hidden benefit: I can quickly search my codebase for any configuration value. Each price change goes through my Git history, ensuring that every alteration is accounted for. Instead of spending a week developing a configuration service, I have made only three changes over the last three months—saving countless engineering hours.

3. Utilizing SQLite in Production

Shockingly, I’m leveraging SQLite for what is essentially a multi-user web application