The Three-Month Rule: A Practical Approach to Unscalable Solutions in Development
In the entrepreneurial tech world, one piece of advice often stands out: “Do things that don’t scale.” While many are familiar with this wisdom from Paul Graham, the challenge lies in translating it into real-world coding practices.
After eight months of developing my AI podcast platform, I’ve formulated a straightforward framework that has proven immensely useful: each unscalable solution is given a life span of three months. If it survives that period, it either validates its worth and undergoes enhancement into a scalable format, or it is abandoned.
As engineers, we’re often conditioned to conceptualize scalable solutions from the outset—microservices, distributed systems, and intricate design patterns to accommodate millions of users. However, this line of thinking is more suited to large enterprises than to startups. In fact, opting for scalable architecture far too early can lead to costly delays, as we devote time to optimizing for hypothetical users and challenges that may never materialize. My three-month rule compels me to embrace straightforward coding practices that deliver results, ultimately guiding me towards understanding my users’ true needs.
My Pragmatic Infrastructure Strategies
1. Centralizing Operations on a Single VM
Everything—database, web server, background jobs, and even Redis—runs on a single $40/month virtual machine. It might sound reckless as there’s no redundancy and I’m relying on manual backups, but this approach has its perks.
In just two months, I’ve gleaned invaluable insights into my platform’s actual requirements, discovering that during peak activity, it utilizes only 4GB of RAM. The complex Kubernetes infrastructure I nearly implemented would have simply wasted resources managing idle containers. When system failures occur (and they have happened twice), I gain practical data on failure points—often revealing surprises.
2. Hardcoding Configurations
Configuration values such as pricing tiers and user limits are hardcoded directly into the application. While this is typically frowned upon in software development, the method has its strengths: immediate accessibility. I can search my entire codebase for any configuration in seconds. Additionally, changes are documented in version control, ensuring that every modification is recorded and easily reviewable.
Crafting a dedicated configuration service could consume a week of my time, but I’ve only modified these values three times in three months, making it a small investment of just 15 minutes per redeployment compared to the extensive engineering effort.
