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

In the entrepreneurial landscape, there’s a familiar phrase from Paul Graham that resonates deeply with startups: “Do things that don’t scale.” While this advice is well-known, the challenge often lies in translating it into actionable coding practices.

Over the past eight months, while developing my AI podcast platform, I’ve crafted a straightforward framework that I’ve dubbed the 3-Month Rule. This principle allows any unscalable workaround to exist for just three months. If it proves its worth within that timeframe, it can evolve into a robust solution; if not, it’s set to be discarded.

As engineers, we are instinctively drawn to creating scalable systems right from the inception of a project. We delve into design patterns, microservices, and complex architectures that can accommodate millions of users. However, this mindset often aligns more with large corporations than with the realities of startups. In many cases, chasing scalability early on can lead to unnecessary expenses and delays, as we often optimize for prospective users rather than addressing existing needs.

By adhering to the 3-Month Rule, I prioritize writing simple, albeit imperfect, code that allows me to ship products and gain authentic insights from user interactions. Here is a closer look at some current infrastructure hacks that may initially seem questionable but have provided invaluable learning experiences.

1. Consolidating Everything on a Single Virtual Machine

I currently operate my database, web server, background tasks, and caching—all on a $40 monthly virtual machine with zero redundancy. While this setup might sound risky, it has forced me to gain a clearer understanding of my resource requirements in just two months. My platform’s peak demand hovers at 4GB of RAM, indicating that the vast Kubernetes architecture I nearly implemented would have been wasted on managing idle containers. Furthermore, every crash (which has happened a couple of times) provides tangible data about failure points, often revealing surprises about what really goes wrong.

2. Using Hardcoded Configuration Settings

My configuration approach is intentionally simplistic—parameters like pricing tiers and user limits are hardcoded directly into the codebase, with no environment variables or separate files. This setup has allowed me to track changes efficiently through version control, with each adjustment captured in the git history. Creating a dedicated configuration service would have consumed a significant amount of time, but considering I have changed these values only three times in the past three months, I’ve saved