Embracing the 3-Month Rule: A Pragmatic Approach to Building Unscalable Solutions
In the world of startups, where agility and adaptability are key, Paul Graham’s advice to “do things that don’t scale” resonates powerfully. Yet, the implementation of this philosophy, particularly in software development, is less frequently discussed. After spending eight months developing my AI podcast platform, I’ve identified a straightforward strategy: each unscalable solution is granted a lifespan of three months. At the end of this period, we assess whether it warrants further investment or should be phased out.
The Problem with Pursuing Scalability Too Soon
As engineers, we often find ourselves programmed to prioritize scalable solutions from the outset. The allure of intricate design patterns, microservices, and robust distributed systems tempts us into architecting solutions meant for a vast user base right from day one. However, in the startup landscape, dedicating time to scalable architectures can often lead to costly delays, as we focus on hypothetical users and potential challenges that may never arise.
Adopting my 3-month rule obliges me to create straightforward, even “messy” code that is functional and, more importantly, instructive. This process reveals genuine user needs and pain points, paving the way for informed development down the line.
Current Infrastructure Strategies and Their Benefits
1. Consolidation on a Single Virtual Machine
All components of my app—including the database, web server, and background processes—operate on a single $40/month virtual machine. While this configuration may seem risky due to a lack of redundancy, it has proven invaluable. Over the last two months, I’ve gained a clearer understanding of my resource requirements than any speculative planning document could provide. For example, I discovered that my platform, which I thought would be “AI-heavy,” only requires 4GB of RAM. Had I opted for a complex Kubernetes infrastructure, I would have simply been managing unused resources.
2. Directly Hardcoded Configurations
Throughout my codebase, I have hardcoded key values—such as pricing tiers and user limits—directly into the files. This approach simplifies updates; with just a quick search, I can locate any configuration and track changes via Git history. Instead of spending weeks creating a dedicated configuration service for changes that have occurred only three times in three months, I’ve spent mere minutes redeploying the application.
3. Utilizing SQLite for Production
Surprisingly, I
