Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Solutions in Development
A well-known piece of advice from Paul Graham encourages entrepreneurs to “do things that don’t scale.” However, the conversation rarely dives into how that applies specifically to coding practices in the tech industry.
In my journey of building an AI podcast platform over the past eight months, I’ve devised a straightforward framework: any unscalable hack gets a lifespan of three months. At the end of that period, it either proves its worth and is built out properly or it gets phased out.
Here’s the truth: as software engineers, we often find ourselves aiming to create scalable solutions right off the bat. We focus on intricate design patterns, robust microservices, and distributed systems—all the components necessary for handling millions of users seamlessly. But that mentality can stifle innovation, especially in a startup environment.
Scalable solutions can sometimes lead to expensive delays. We end up optimizing for potential users who may never exist, while neglecting the pressing needs of the ones we have right now. My 3-month rule encourages me to adopt a more minimalist approach, allowing me to draft simple, somewhat “messy” code that gets deployed quickly and reveals genuine user needs.
Current Hacks in My Infrastructure: The Rationale Behind Them
1. Consolidation on a Single VM
My setup includes the database, web server, background jobs, and Redis—all running on one $40/month virtual machine, with no redundancy and manual backups to my local system.
Why is this smart rather than reckless? In just two months, I’ve gained more insight into my resource demands than any extensive planning document could offer. Surprisingly, my AI-centric platform only peaks at 4GB of RAM. The ambitious Kubernetes setup I was contemplating would have been wasted on idle resources.
Each crash teaches me valuable lessons about what components truly falter under pressure, and it’s rarely what I anticipated.
2. Direct Config Hardcoding
Instead of relying on config files or environment variables, I’ve opted for hardcoded constants sprinkled throughout my codebase. Adjusting any of these values requires a redeployment.
What’s the advantage? I can instantly search my entire codebase for any configuration item. Every price adjustment is documented in my Git history, and each change undergoes my personal code review. Developing a separate configuration service would consume a week of development—yet I’ve altered these constants only three times in three months. That’s a mere 15
