Embracing Imperfection: The 3-Month Rule for Scalable Coding
In the realm of tech startups, there’s a ubiquitous piece of advice floating around from Paul Graham: “Do things that don’t scale.” While this concept is often embraced, the practical implementation, particularly in coding, is frequently overlooked. As a developer working on my AI podcast platform over the last eight months, I have devised a straightforward approach that I refer to as the “3-Month Rule.” This principle allows any unscalable hack a tenure of three months. If it proves its worth, it earns a proper development effort; otherwise, it faces elimination.
The Challenge of Scalability
As engineers, we are conditioned to prioritize scalable solutions from the outset. We often bury ourselves in the intricacies of design patterns, microservices, and distributed systems—all impressive architectures designed to accommodate millions of users. However, this kind of thinking suits large corporations far better than startups. Often, what we perceive as scalable code can no longer be justified; it becomes a costly form of procrastination, optimizing for a user base that doesn’t exist yet. The 3-month guideline compels me to write straightforward, imperfect code that can be deployed quickly, allowing me to gauge actual user needs more effectively.
Examples of My Current Infrastructure Choices
1. Consolidated on a Single VM
Imagine hosting your database, web server, background jobs, and more, all on a single $40-per-month virtual machine. It sounds precarious, but the insights gained in just two months have far outweighed the risks. This simplified setup has revealed that my platform only requires 4GB of RAM, rendering my initial plans for a complex Kubernetes architecture unnecessary. When my system does crash—twice so far—I receive valuable data on points of failure, often surprising me.
2. Hardcoded Configuration Parameters
Instead of using configuration files or environment variables, I have hardcoded constants directly into my source code. Consider this snippet:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
While it may seem inefficient, it allows me to swiftly locate and change configuration values, with each adjustment documented in git history. Over three months, I’ve changed configurations only three times—far less than the effort it would take to build and maintain a dedicated configuration service.
