Embracing the 3-Month Rule: A Strategic Approach to Unscalable Coding
In the startup world, the mantra “Do things that don’t scale,” popularized by Paul Graham, is frequently cited. However, practical application of this principle in coding discussions is often overlooked. During my eight-month journey building an AI podcast platform, I discovered a straightforward framework that I now call the “3-Month Rule.” This approach allows each unscalable solution to exist for just three months, after which it is assessed for its value. If a solution proves beneficial, it is then restructured appropriately; if not, it is discarded.
Traditionally, engineers lean toward creating scalable solutions from the outset. We gravitate toward elaborate architectures involving microservices, distributed systems, and sophisticated design patterns that cater to millions. While this mindset might serve large organizations, startups often find that such scalability becomes an expensive form of procrastination. By focusing on hypothetical users and potential future issues, we overlook the immediate needs of our actual user base. My 3-Month Rule encourages a more stripped-down approach: writing straightforward, albeit imperfect, code that can ship quickly and illuminate user needs in real time.
Ingenious Infrastructure Hacks That Serve a Purpose
1. Single VM Approach
All components of my platform—database, web server, background jobs, and Redis—run on a single $40/month virtual machine. While it lacks redundancy and relies on manual backups, this strategy has yielded rich insights. In just two months, I’ve gained a clearer understanding of my actual resource demands than I would have through a traditional capacity planning document. I’ve observed my platform typically peaks at around 4GB of RAM, meaning that the complex Kubernetes architecture I almost installed would have merely handled dormant containers. Each crash (a total of two thus far) has provided unexpected insights into what truly fails—information I wouldn’t have gleaned otherwise.
2. Hardcoded Configuration
My configuration is straightforward yet effective:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
Instead of relying on configuration files or environment variables, I’ve opted for hardcoded constants throughout the codebase. The result? Fast and simple access. A quick grep allows me to track any config value instantly, and each change is documented in Git. Building a robust configuration service would take a
One Comment
Thank you for sharing your insights on the 3-Month Rule—it’s a refreshing perspective that emphasizes rapid iteration and learning over premature optimization. I especially appreciate your emphasis on starting simple and allowing real-world usage to guide infrastructure and architectural decisions. Your single VM approach is a great example of how practical experimentation can yield immediate insights and prevent overengineering, particularly valuable in startup environments where speed is crucial.
The hardcoded configuration strategy also resonates; while it might seem counterintuitive from a traditional engineering standpoint, it enables quick adjustments and a clearer understanding of what truly affects the system. Of course, this approach should be used judiciously, especially as the product matures, but it underscores the importance of prioritizing agility during early development stages.
Overall, your framework supports a mindset shift—focusing on validated learning and incremental scaling rather than pre-emptive complexity. It could be beneficial to explore how this approach integrates with subsequent phases of scaling, ensuring that the initial simplicity doesn’t hinder future robustness. Thanks again for sparking this valuable discussion!