Embracing the 3-Month Rule: A Practical Approach to Implementing Unscalable Solutions
When it comes to building a startup, the advice usually boils down to one succinct mantra: “Do things that don’t scale.” While this notion, popularized by Paul Graham, is commonly acknowledged, the challenge lies in translating it into actionable steps—especially when it comes to coding. Over the last eight months, during the development of my AI podcast platform, I have devised a straightforward yet effective framework known as the “3-Month Rule” for managing unscalable hacks. This approach grants every experimental solution a lifespan of three months. At the end of that period, we assess its value: it either gets refined into a robust solution or is phased out.
As engineers, we are often conditioned to seek scalable solutions right from the onset. We immerse ourselves in design patterns, microservices, and distributed systems—all elements that cater to the needs of millions of users. However, this mindset can be limiting, especially for startups, where aiming for scalability can sometimes translate into costly delays. The 3-Month Rule encourages me to write straightforward, sometimes imperfect code that leads to valuable insights about real user needs.
Lessons from My Current Infrastructure Hacks
Let’s delve into some of the current infrastructure hacks I’m employing and discuss why they are not only acceptable but, in some cases, smart choices.
1. Consolidating Resources on a Single Virtual Machine
I host my database, web server, background jobs, and Redis all on a single VM costing just $40 per month. While this setup lacks redundancy and relies on manual backups, the key takeaway has been understanding my actual resource needs. In a mere two months, I discovered that my platform’s peak usage hovers around 4GB of RAM—information that would have been obscured by an overly complex infrastructure. Despite its simplicity, this method has provided invaluable data on unexpected crashes and user behavior.
2. Hardcoded Configurations for Simplicity
Instead of utilizing config files or environment variables, I’ve opted for hardcoded constants, such as pricing tiers and database limits, directly within my files. Although some might view this as a step backward, it allows for rapid tracking and changes when necessary. The time saved by avoiding the development of a configuration management service—just 15 minutes spent redeploying versus potentially 40 hours of engineering—is a clear win.
3. Using SQLite for Production
Yes
