Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions in Engineering
In the tech startup arena, the often-quoted wisdom from Paul Graham rings true: “Do things that don’t scale.” Yet, the conversation rarely delves into how to practically implement this philosophy during the coding process. After eight months of developing my AI podcast platform, I’ve crafted a straightforward framework. Each unscalable solution I employ is given a lifespan of three months. At the end of this period, it must either demonstrate its value and transition into a robust solution or be discarded.
As engineers, we are typically conditioned to create scalable solutions right from the start. We become enamored with concepts like design patterns, microservices, and distributed systems—architectural ideals that can support millions of users. However, this perspective tends to skew towards the mindset of larger companies.
For a startup, striving for scalability too early can be a costly form of procrastination. We often find ourselves optimizing for a future user base that may never materialize, tackling issues that may never arise. My three-month rule compels me to write code that is straightforward, sometimes even considered “bad,” but ultimately enables me to learn what users genuinely need.
Insights from My Current Infrastructure Hacks
1. Single VM Operations
I’ve consolidated my database, web server, background jobs, and Redis onto a single $40/month virtual machine. While this setup lacks redundancy and relies on manual backups, the data I’ve gathered over the past two months has provided invaluable insights into my resource requirements. Surprisingly, my AI-centric platform peaks at only 4GB of RAM. The intricate Kubernetes architecture I nearly implemented would have meant managing empty containers instead. Each time the system crashes (which has happened twice), I gain real insights into actual points of failure—often different from my initial assumptions.
2. Hardcoded Constants
My configuration is straightforward:
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
With no separate configuration files or environment variables, changes require a redeployment. However, the advantage is that I can quickly search my entire codebase for any configuration value and easily track changes through Git history. In three months, I’ve modified these values only three times, saving countless hours of development effort.
