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

In the startup world, the famous advice from Paul Graham—”Do things that don’t scale”—is often quoted but rarely unpacked. As someone who has been diligently developing an AI podcast platform for the past eight months, I’ve adopted a straightforward yet effective strategy: every unscalable workaround has a lifespan of just three months. At the end of this period, if the method proves its worth, it gets developed into a robust solution; if it doesn’t, it’s discarded.

As engineers, we’re trained to prioritize scalability from the outset, employing design patterns, microservices, and distributed systems to accommodate large user bases. However, this approach can be counterproductive for startups. Optimizing for future users can lead to expensive delays and ineffective solutions, making the task of actually engaging real users cumbersome. My three-month rule encourages me to create simple, pragmatic—even “imperfect”—code that allows for immediate learning and a deeper understanding of user needs.

Insights Gained from Current Infrastructure Hacks

1. Consolidated Resources on a Single VM

My setup consists of a single virtual machine that runs the database, web server, background jobs, and Redis—all for just $40 a month. While lacking redundancy and depending on manual backups, this configuration has proven invaluable. In just two months, I’ve gleaned insights into my actual resource consumption that no amount of theoretical planning could provide. For instance, my application peaks at 4GB of RAM. Had I invested time in a Kubernetes architecture, I would have spent precious resources managing non-existent load.

2. Simplified Configuration Management

Instead of employing external configuration files or environment variables, I’ve opted for hardcoded constants throughout my codebase. While this may seem reckless, the ease with which I can search for and alter configuration values has made it worthwhile. With only three changes in three months, the time spent redeploying has been negligible compared to what it would have taken to develop an entire configuration management service.

3. SQLite as a Production Database

Choosing to utilize SQLite for a multi-user environment might seem unconventional, but my database occupies a mere 47MB and can accommodate 50 concurrent users effortlessly. Through this choice, I’ve learned that my access patterns are predominantly read-based, which aligns perfectly with SQLite’s strengths. If I had chosen Postgres from the start, I would have wasted time optimizing systems