Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Solutions
In the world of startups, the advice from Paul Graham to “do things that don’t scale” is often regurgitated but seldom put into practice, especially within the realm of software development. Over the past eight months, while working on my AI podcast platform, I’ve devised a straightforward yet effective framework: every unscalable solution is permitted a life span of three months. After this period, it either proves its worth and is revamped into a scalable version, or it is retired.
As engineers, we are conditioned to focus on crafting scalable solutions right from the outset. We often find ourselves tangled in complex design patterns and sophisticated architectures suited for handling large volumes of users. However, adopting such a mindset can lead to unnecessary delays in a startup environment. The reality is that prematurely optimizing for future users can result in spending time and resources on problems that may never arise.
My 3-month rule compels me to write straightforward and intentionally “suboptimal” code that can actually be deployed. This approach allows me to gain invaluable insights into what users genuinely require.
Current Infrastructure Hacks That Are Surprisingly Effective:
1. Single VM Setup
I run my entire operation—a database, web server, background jobs, and Redis—on a single $40/month virtual machine without redundancy and perform manual backups to my local storage.
This strategy has proven to be astute; I’ve gained more understanding of my resource requirements in just two months than any capacity planning document could provide. Fascinatingly, my AI-centric platform operates efficiently with only 4GB of RAM. Had I opted for a more advanced setup like Kubernetes, I would have been left managing empty containers much of the time.
2. Hardcoded Configuration Values
My code is filled with constants like:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
Without configuration files or environment variables, changing any values necessitates a redeploy.
The benefit of this approach lies in the simplicity it affords me. I can quickly search my codebase for any configuration in seconds. Each price alteration is documented within git history, and every configuration update goes through code review—even if it’s just me reviewing my own pull request.
Rather than spending a week developing a configuration service, I’ve made just three changes in
