Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Solutions
In the tech startup world, the common wisdom often echoes Paul Graham’s philosophy: “Do things that don’t scale.” But how do we translate this principle into practical coding strategies? After eight months of developing an AI podcast platform, I’ve established a straightforward framework: unscalable hacks are granted a trial period of three months. If they prove beneficial, they will be refined and built out; otherwise, they will be discarded.
As engineers, we frequently find ourselves striving to create scalable solutions from day one. We immerse ourselves in architectural designs, microservices, and distributed systems, all crafted with the capability to accommodate millions of users. However, such foresight often reflects the mentality of larger organizations.
In a startup environment, focusing on scalability too early can lead to costly delays. You risk pouring time into optimizing for hypothetical users and addressing future complications that may never arise. My 3-month rule compels me to develop straightforward, albeit “imperfect,” code that can be implemented quickly, allowing me to explore the actual needs of users effectively.
Current Infrastructure Innovations
1. Unified VM Setup
I’m operating everything on a single $40/month virtual machine that hosts my database, web server, background jobs, and Redis. This setup is intentionally without redundancy and relies on manual backups to my local device.
Why is this approach effective? In just two months, I’ve gained invaluable insights into my true resource needs, far beyond what any capacity planning document could offer. For instance, my “AI-heavy” platform peaks at merely 4GB of RAM. The Kubernetes configuration I nearly implemented would have meant managing empty containers instead of addressing real demands.
Every time the system crashes—twice so far—I gather practical data about failures which often surprise me, as they’re rarely aligned with my predictions.
2. Hardcoded Configuration
I’m utilizing constants throughout my codebase for configuration values such as:
plaintext
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
There are no complex configuration files or environment variables. Adjusting any value necessitates redeployment, but this comes with its own advantages. With a simple grep, I can search my entire codebase for any configuration value in seconds, and every change is meticulously tracked in Git history. Although
