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
