Embracing the 3-Month Rule: A Practical Approach for Startups
When it comes to startup culture, few phrases resonate as much as Paul Graham’s advice to “do things that don’t scale.” However, translating this philosophy into actionable coding practices often goes unaddressed. After spending eight months developing my AI podcast platform, I’ve crafted a straightforward framework: every unscalable hack is given a lifespan of just three months. At the end of this period, we reassess: if it has delivered tangible value, we build it out properly; if not, it gets the axe.
As engineers, we tend to lean heavily on the creation of scalable solutions right from the start. Whether it’s intricate architecture for handling millions of users or advanced techniques like microservices, we often find ourselves trapped in the mindset of big organizations. But in the world of startups, implementing scalable code can become a costly diversion. We’re frequently optimizing for future users who aren’t even in the pipeline yet or tackling problems that might never arise. My three-month guideline encourages me to focus on direct, no-frills code that actually gets deployed while allowing us to discover what users truly require.
Current Infrastructure Hacks and Their Surprising Benefits
1. Consolidation on a Single Server
Everything runs from one virtual machine (VM)—the database, the web server, the background jobs, and even Redis—all for just $40 a month. There’s no redundancy, and backups are done manually.
This approach provides valuable insights about our resource usage. In less than two months, I’ve learned that my “AI-heavy” platform typically requires just 4GB of RAM. A complex Kubernetes setup would have been a waste of time managing empty containers. And when the server crashes (which has happened a couple of times), I get genuine feedback on system vulnerabilities—often in ways I didn’t anticipate.
2. Hardcoded Values for Configuration
With constants like:
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
There are no external config files or environment variables—just hardcoded values throughout my codebase. Modifying any parameter necessitates a redeployment.
This strategy allows for rapid searches across my codebase for specific configurations. Price changes are easily tracked through Git history and reviewed in a straightforward way. Devoting a week to build a configuration service seems pointless when I’ve only made three changes in three
