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

In the realm of entrepreneurship and engineering, the wisdom of Paul Graham resonates strongly: “Do things that don’t scale.” However, when it comes to practical implementation—especially in coding—this idea can often be overlooked.

After dedicating eight months to developing my AI podcast platform, I devised a straightforward methodology: every unscalable approach I adopt receives a trial period of three months. At the end of this timeframe, the approach must demonstrate its value and earn a proper build-out, or it will be discarded.

As engineers, we typically prioritize scalable solutions from the outset—design patterns, microservices, and complex architectural frameworks are at the forefront of our thinking. However, this mindset often leads to an expensive delay in startups, optimizing for potential users that may not yet exist and addressing issues that may never arise. My three-month rule compels me to create straightforward, albeit imperfect, code that actually gets deployed. This invaluable process allows me to understand the genuine needs of my users.

Here’s a Look at My Current Strategic Hacks and Their Significance:

1. Consolidation on a Single VM

I’ve consolidated my database, web server, background jobs, and Redis onto a single $40/month virtual machine. While this setup lacks redundancy and relies on manual backups, it’s taught me about my actual resource requirements far more effectively than any theoretical capacity document. I’ve discovered, for instance, that my “AI-heavy” platform peaks at just 4GB of RAM. The intricate Kubernetes architecture I almost implemented would have only served to manage empty containers. Each crash (and there have been a couple) provides me concrete insights into failure points—often surprising ones.

2. Hardcoded Configuration

With constants such as PRICE_TIER_1 = 9.99 and MAX_USERS = 100 dispersed throughout my codebase, I’ve opted for hardcoded configurations instead of using config files or environment variables. While changing values necessitates a redeployment, this method presents a unique advantage. I can quickly search my entire codebase for any configuration value, tracking changes through my Git history. Since I’ve only modified key parameters thrice over the last three months, this approach saves hours of engineering effort while enabling rapid adaptations.

3. SQLite in Production

Contrary to typical expectations, my multi-user web app operates on SQLite, a mere 47MB in size. It