The 3-Month Rule: A Technical Framework for Embracing Unscalable Solutions
When it comes to building products, many of us are familiar with the wisdom of Paul Graham: “Do things that don’t scale.” However, the application of this principle in software development often goes unexplored.
As I have spent the past eight months developing my AI podcast platform, I’ve established a straightforward framework: allow each unscalable approach or hack to exist for a limited time of three months. After this period, it either proves its worth and evolves into a robust solution, or it is phased out.
It’s essential to recognize that as engineers, we are often conditioned to prioritize scalable designs from the outset—thinking in terms of elegant architectures, microservices, and systems capable of accommodating millions of users. While this approach is valuable for large enterprises, in the startup ecosystem, it can lead to excessive investment in solutions for problems that may never arise. My three-month rule encourages me to create straightforward, even “poorly-designed” code that enables rapid deployment and insightful learning about real user needs.
Infrastructure Choices: Why My Current Hacks Work
1. Unified VM for Everything
I’ve opted to run my entire infrastructure—database, web server, background processes, and caching—on a single virtual machine costing just $40 a month, with zero redundancy and manual local backups.
This decision has proven to be strategic rather than foolish. Within a span of two months, I’ve gained invaluable insights into my actual resource requirements. For instance, I’ve discovered that my platform peaks at 4GB of RAM, underscoring how unnecessary a complex Kubernetes setup would have been. When crashes have occurred (and they have twice), I’ve identified the real causes—not always what I anticipated.
2. Hardcoded Configuration
My configuration is essentially hardcoded: constants like PRICING and MAX_USERS are embedded directly in the codebase.
Though this might seem counterintuitive, it simplifies tracking and modifying configurations. Every change is documented in version control, and I can quickly search the codebase for any value. Building a configuration service would require significant development time, but since I’ve only changed settings three times in three months, this straightforward method has saved me countless engineering hours.
3. Utilizing SQLite in Production
Yes, SQLite is powering my multi-user web application, and it’s performing admirably with a total database size of 47MB, effortlessly managing 50 simultaneous users.
This choice has illuminated key access
One Comment
Great insights! Your 3-month rule is a practical approach that aligns well with the Lean Startup philosophy—prioritizing rapid experimentation and learning over premature optimization. I particularly appreciate your emphasis on understanding real usage and resource needs before investing in complex or scalable architectures.
Using a single VM and hardcoded configs visibly lowers the barrier to rapid iteration, enabling focused validation of core ideas. Additionally, your experience with SQLite underscores that sometimes, “good enough” solutions are sufficient for early-stage products, allowing you to allocate resources more strategically as the platform grows.
Looking ahead, it might be interesting to consider how you plan to evolve these unscalable hacks as your user base and needs grow. Transitioning from quick-and-dirty solutions to more scalable architectures can be a natural progression once you’ve validated your core product-market fit. Your framework provides a solid foundation for that evolution—thanks for sharing this thoughtful approach!