Embracing the 3-Month Rule: A Practical Approach to Building Unscalable Solutions
In the world of entrepreneurship, it’s common to come across the guidance of Paul Graham, who famously advised to “do things that don’t scale.” While this advice is readily available, a deeper exploration into how to effectively implement it within the realm of software development often goes unaddressed.
Over the past eight months, I’ve been working on building an AI podcast platform, and through this experience, I’ve developed a straightforward yet powerful framework: every unscalable solution is given a lifespan of just three months. After this period, the idea must either prove its worth and be built out properly or be discarded.
The Problem with Scalable Coding from the Start
As engineers, our training often leads us to prioritize scalability from the outset. We design intricate architectures featuring design patterns, microservices, and distributed systems—all intended to cater to countless users. However, this mindset is often more suitable for larger organizations than for startups.
In reality, focusing on scalable solutions too early can be a form of costly procrastination. We may end up spending time optimizing for hypothetical users and addressing issues we might never encounter. My 3-month rule compels me to focus on simpler coding approaches that are effective and rapid in delivering insights into user needs.
Innovative Infrastructure Hacks That Work for Me
Below are some of the unscalable hacks I’m currently employing, which actually serve a valuable purpose.
1. Consolidated Infrastructure on a Single VM
Rather than distributing components across multiple servers, I operate everything—database, web server, background processes, and caching—on a single $40/month virtual machine. There’s no redundancy, and backups are handled manually.
Why is this beneficial? In just two months, I have gained invaluable insights into my actual resource usage, far beyond what any capacity planning document could provide. My platform peaks at 4GB of RAM, a revelation that rendered my initial Kubernetes setup unnecessary and would have meant managing idle containers.
When issues do arise (which they’ve twice), I gain specific data about the failure points, which are often unexpected.
2. Hardcoded Configuration Across Codes
I use hardcoded constants for configurations—price tiers, user limits, and AI models—rather than relying on external configuration files or environment variables.
This may seem limiting, but it allows for quick searches through the codebase and precise tracking of changes via version history. In three months, I’ve
One Comment
This post offers a compelling perspective on balancing experimentation with practicality, especially for startups and early-stage projects. The 3-month rule effectively encourages rapid iteration and learning without getting bogged down in unnecessary complexity. I particularly appreciate the emphasis on starting with simple, unscalable solutions to gain real user insights quickly—that aligns well with the lean startup philosophy.
Your infrastructure hacks are insightful: consolidating to a single VM and hardcoding configurations may seem counterintuitive in a traditional engineering context, but as you’ve observed, they provide invaluable clarity during initial validation phases. This approach minimizes overhead, accelerates feedback loops, and helps identify true bottlenecks before investing in scalable architecture.
One point to consider is establishing a clear exit or upgrade strategy after the three months. Knowing when to move from unscalable hacks to more robust, scalable solutions is crucial to sustain growth without falling into the trap of stubbornly clinging to early-stage shortcuts.
Thanks for sharing this practical framework—it’s a valuable reminder that sometimes, doing things that don’t scale is the fastest path to understanding user needs and building a foundation for scalable growth.