Embracing the 3-Month Rule: A Pragmatic Framework for Engineering Startups

In the world of startups, the age-old wisdom of Paul Graham rings true: “Do things that don’t scale.” However, the practicalities of how to implement this advice in a coding environment are often overlooked. Over the past eight months while developing my AI podcast platform, I have formulated a framework that has yielded significant insights into the coding process: the 3-Month Rule. This straightforward principle allows each non-scalable hack a lifespan of three months—after which it must either prove its worth and evolve into a sustainable solution, or it will be scrapped.

The Challenge of Scalability in startup Environments

As software engineers, we are often conditioned to prioritize scalable solutions from the outset. The allure of robust architecture—complete with design patterns, microservices, and distributed systems—appeals greatly in environments where user numbers can soar into the millions. However, in a startup scenario, obsessively focusing on scalability can lead to unnecessary expenses, as it often means building for users that don’t yet exist and addressing problems that may never arise.

The 3-Month Rule has compelled me to embrace simpler, more direct coding practices that prioritize shipping over perfection and, most importantly, that reveal the true needs of my users.

Current Infrastructure Strategies: Lessons Learned

Let’s explore some of the unconventional practices I’ve adopted, each proving to be a savvy choice rather than an oversight:

1. Single-VM Deployment

My entire setup runs on a $40/month virtual machine that houses the database, web server, background jobs, and Redis, with no redundancy and manual backups. This arrangement, while seemingly precarious, has allowed me to comprehend my resource requirements far better than any forecasting document could. Through experience, I discovered that my “AI-heavy” platform only peaks at 4GB of RAM. The Kubernetes system I almost deployed would have been a complex solution managing unoccupied containers. When failures occur (which they have, on two occasions), I gather concrete data about what truly breaks—often different from my initial assumptions.

2. Hardcoded Configuration Values

Configuration constants like pricing tiers and user limits are scattered throughout my files without any sophisticated configuration management. While deploying new changes requires a redeployment, the simplicity enables quick searches throughout the codebase for any value, with every alteration tracked via version control. Creating a separate configuration service would be a week-long undertaking, yet I’ve