Embracing the 3-Month Rule: A Framework for Scaling Smartly in Startups
In the entrepreneurial landscape, there’s an often-quoted piece of advice from Paul Graham: “Do things that don’t scale.” However, the implementation of this guidance, especially in the realm of coding, remains less discussed. After spending eight months building my AI podcast platform, I’ve devised a pragmatic framework to integrate this principle into my workflow: every unscalable hack is given a lifespan of three months. After this period, it either demonstrates its worth and gets the proper structure it deserves or it gets retired.
Understanding the Challenge
As engineers, we are conditioned to pursue scalable solutions right off the bat. Concepts like design patterns, microservices, and distributed systems feel alluring, particularly when envisioning a platform that might one day support millions of users. However, at a startup, investing time in building a perfectly scalable architecture can often evolve into procrastination disguised as optimization—especially when that scalability caters to hypothetical users and not the current ones.
My 3-month rule compels me to prioritize expediency and learning over premature optimization. It allows me to create rudimentary, straightforward, yet functional code that leads to real user insights.
My Strategic Infrastructure Choices
Here are some of my current architectural decisions—far from conventional—but incredibly effective in what I aim to achieve:
1. Single VM Dependency
By hosting my database, web server, background jobs, and Redis all on a single $40/month virtual machine, я maintain zero redundancy and manage manual backups to my local machine.
Why this approach works: In just two months, I’ve gained more knowledge about my actual resource needs than any extensive capacity planning document could have provided. For example, I discovered that my platform, which I initially assumed would require immense resources, peaks at just 4GB of RAM. The complex Kubernetes configuration I almost instituted would have resulted in managing redundant systems.
2. Hardcoded Configuration
I utilize hardcoded constants directly in my code for pricing and user limits:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
The strategic advantage: This allows me to effortlessly search my entire codebase for configuration parameters within seconds. Every price adjustment is logged in git history and reviewed (even if it’s just my own review). The process of building a dedicated configuration service would consume significant
