Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions

In the world of startups, where agility and innovation are paramount, it’s common to encounter the sage advice from Paul Graham: “Do things that don’t scale.” However, the real challenge lies in effectively applying this concept—particularly in the realm of coding.

After dedicating the past eight months to developing an AI podcast platform, I’ve devised a straightforward strategy that I call the “3-Month Rule.” This framework stipulates that each non-scalable solution is granted three months to determine its viability. At the end of this period, it either demonstrates its worth and is transformed into a robust system or is discarded altogether.

The Challenge of Scalable Thinking

In our training as engineers, we’re often conditioned to focus on building scalable architectures from the outset—leveraging design patterns, microservices, and distributed systems that are meant to handle vast user bases. While appealing, this mindset is often representative of large corporations rather than startups.

At a startup, the pursuit of scalability can quickly become a costly exercise in procrastination. We may find ourselves optimizing for hypothetical users and addressing challenges that may never arise. My 3-month rule compels me to create straightforward, albeit imperfect, code that not only gets delivered but also provides invaluable insights into the real needs of users.

Current Infrastructure Practices: Unpacking the Methodology

Here are some of my current “hacks” and the rationale behind them:

1. Single Virtual Machine (VM) Deployment

I’ve consolidated my database, web server, background jobs, and Redis into a single $40/month VM. While it may lack redundancy, this approach has provided profound insights into my resource consumption. I’ve learned that my resource-intensive platform peaks at just 4GB of RAM, sparing me from overcomplicating my architecture. Crashes, which have occurred twice, have offered real-world data on my system’s weaknesses—data that enhances my understanding far more than theoretical capacity planning could.

2. Hardcoded Configuration

Instead of relying on configuration files or environment variables, I employ hardcoded constants, such as pricing and user limits, throughout my codebase. This tactic might seem inefficient, but it allows me to quickly locate configurations across the entire project and track changes systematically through version control. The time savings from this method have significantly outweighed any drawbacks, demonstrating that effective simplicity often trumps overengineering.