The 3-Month Rule: A Practical Approach to Unscalable Solutions in Tech
In the world of startups, the mantra “do things that don’t scale” often echoes, particularly in the advice given by influential figures like Paul Graham. However, the challenge lies in translating this concept into practical coding techniques. After eight months of cultivating my AI podcast platform, I’ve adopted a straightforward framework: every unscalable approach gets a lifespan of three months. At the end of this period, we either solidify its value through proper implementation, or we eliminate it.
As engineers, our instinct is often to focus on crafting scalable solutions from the outset. We immerse ourselves in design patterns, microservices, and robust architectures intended to cater to millions of users. However, this line of thinking can prove to be counterproductive in a startup environment. Prioritizing scale too early can lead to wasted resources by solving problems that simply don’t yet exist.
My three-month rule encourages me to produce straightforward and sometimes suboptimal code that can be quickly deployed, giving me invaluable insights into user behavior and needs rather than getting bogged down in intricate solutions.
Current Infrastructure Hacks: Insights from My Approach
1. A Single VM for All Operations
All aspects of my platform—including the web server, database, and background jobs—operate on a single $40/month virtual machine (VM). While this setup lacks redundancy and relies on manual local backups, it has been an invaluable testing ground. Within two months, I gained real insights into my resource requirements, revealing that my platform, initially thought to be “AI-heavy,” only peaks at 4GB RAM usage. My initial thoughts of implementing a complex Kubernetes setup would have merely involved managing idle containers. Each time the system experiences a crash, I gather data about what caused the issue—something I would not have anticipated.
2. Hardcoded Configurations
In my code, configurations are hardcoded as constants, with example declarations like:
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
There are no separate configuration files or environment variables, which means any changes necessitate a redeployment. This choice simplifies tracking changes in my Git history and allows for rapid adjustments. Instead of spending a week building a configuration service, I’ve only made three changes in three months—saving significant time and
