Embracing the 3-Month Rule: A Technical Framework for Non-Scalable Solutions
In the realm of startups and software development, the mantra “Do things that don’t scale,” popularized by Paul Graham, resonates with many. Yet, implementing this advice in the coding world often remains uncharted territory. After eight months of building my AI podcast platform, I’ve crafted a straightforward technical framework: every unscalable solution is given a lifespan of just three months. At the end of this period, we assess its value—either it evolves into a robust solution or it gets phased out.
As engineers, we’re often conditioned to prioritize scalable solutions from the start. We engage with design patterns, microservices, and distributed systems—architectural marvels geared toward handling millions of users. However, this type of thinking typically suits larger companies, leaving startups in danger of suffering from premature optimization. In many cases, developing scalable code can turn into costly procrastination, focusing on hypothetical users while neglecting the real ones currently engaging with the product. My three-month rule has pushed me to create simple, straightforward code that ships quickly, providing valuable insights into what users actually need.
Current Infrastructure Practices: Smart Hacks for Efficient Learning
1. Unified Infrastructure on One Virtual Machine
Everything—database, web server, background jobs, and Redis—runs on a single, modestly priced $40/month virtual machine (VM). There’s no redundancy, and backups are done manually to my local machine.
Why is this a masterstroke rather than a blunder? In a mere two months, I’ve gained insights into my actual resource requirements that far exceed what any capacity planning document could offer. My supposedly “AI-heavy” platform operates comfortably within a peak of 4GB of RAM. With the complicated Kubernetes setup I nearly adopted, I’d have found myself managing empty containers instead of addressing real usage patterns.
When the system crashes (and it has, twice), I glean authentic data on what fails—inevitably revealing surprising truths.
2. Hardcoded Configuration Throughout
In my codebase, configurations like price tiers and maximum users are hardcoded as constants. There are no configuration files or environment variables; any modification requires a redeployment.
The brilliance of this approach? I can swiftly search my entire codebase to find any configuration value. Each price adjustment is tracked in Git history, and every change goes through a personal code review. The thought of creating a configuration service without any immediate need was a
One Comment
This is a compelling approach that emphasizes rapid iteration and learning over premature architectural complexity. I appreciate how the 3-month rule forces prioritization—shifting the focus from building perfect, scalable solutions to gaining valuable user insights and actionable data early on.
Your example of consolidating infrastructure onto a single VM highlights an often-overlooked truth: simplicity can reveal much more about real-world needs than elaborate setups. It’s a reminder that resource constraints and minimal setups are powerful tools for experimentation and validation, especially for startups and early-stage projects.
Additionally, the hardcoded configurations exemplify a pragmatic mindset—prioritizing speed and clarity during initial phases, while maintaining version control for traceability. As you iterate beyond this initial phase, it might be worth considering gradual abstraction of these configs to facilitate future scaling and flexibility.
Overall, your framework encourages a disciplined yet flexible approach that balances immediate experimentation with strategic thinking—an inspiring model for engineering teams aiming to deliver value swiftly while avoiding unnecessary complexity.