Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Coding
In the world of startups, the phrase “do things that don’t scale” is often cited, particularly by thought leaders like Paul Graham. Yet, there is a notable absence of concrete strategies for applying this concept to coding practices. Drawing from my eight-month journey of developing an AI podcast platform, I’ve crafted a straightforward guideline I call the “3-Month Rule.” This framework allows every temporary hack I employ to exist for three months. After this period, it must either demonstrate its worth and undergo a polished transformation or face termination.
As engineers, our instincts push us towards building scalable systems right from the outset. We envision intricate architectures filled with design patterns, microservices, and distributed systems—all designed to cater to a vast number of users. Yet, as a startup founder, I’ve come to realize that oftentimes, constructing scalable code in its nascent stages is merely a costly form of procrastination. In my experience, optimizing for non-existent users often leads to solutions for problems that may never occur.
The 3-Month Rule compels me to write uncomplicated, straightforward code that prioritizes shipping over perfection, giving me insights into what truly serves my users’ needs.
Current Strategies: Ingenious Infrastructure Hacks
1. Centralized Operations on a Single VM
Currently, my database, web server, and background jobs all operate on one, inexpensive $40/month virtual machine. While this may appear reckless, the insights gained have been invaluable. I’ve learned more about my resource allocations in two months than from any planning document. For example, my platform only requires 4GB RAM during peak usage, negating the need for a complex Kubernetes setup that would only manage idle resources. Each crash reveals unexpected vulnerabilities, enabling real learning and adaptation.
2. Hardcoded Constants for Configuration
Rather than utilizing configuration files or environment variables, I have opted for hardcoded constants throughout my codebase. While this may seem primitive, it offers significant advantages. My ability to quickly locate any configuration value with a simple search saves me hours over creating a formal configuration service that would have consumed a week of engineering time. Over three months, I’ve made minimal changes—collectively taking just 15 minutes to redeploy.
3. SQLite as a Production Database
Running SQLite in a production environment for a multi-user application might raise eyebrows, but it has been remarkably effective. My database
