Embracing the 3-Month Rule: A Tactical Approach to Unscalable Solutions in Software Development
In the tech world, one often hears the mantra, “Do things that don’t scale,” popularized by Paul Graham. However, the challenge lies not in understanding this principle but in applying it, especially in the realm of coding. After eight months of developing my AI podcast platform, I’ve crafted a straightforward yet effective framework: every unscalable hack is given a lifespan of three months. At the end of this period, the hack must either demonstrate its worth and be fully developed, or it gets discarded.
The common mentality among engineers is to design scalable solutions from the outset, focusing on microservices, distributed systems, and other complex architectures intended to support millions of users. This approach, while beneficial for larger companies, often leads to unnecessary complications in a startup environment. In fact, scalable solutions can become a means of delaying critical learning, as they cater more to hypothetical future users than to actual ones. My 3-month rule encourages the development of straightforward, sometimes “bad,” code that can be deployed quickly, providing real insights into user needs.
Exploring My Current Infrastructure: Innovations That Work
1. Centralized Operations on a Single Virtual Machine
I’ve consolidated my database, web server, background jobs, and caching all into a single $40/month virtual machine. This setup offers minimal redundancy and relies on manual backups to my local storage.
The rationale behind this seemingly risky choice? I’ve gained invaluable insights into my resource requirements in just two months. My platform’s peak demand was only 4GB of RAM, illustrating that the complex Kubernetes architecture I considered would have gone unused. Each time the system crashes (which has happened twice), I can analyze the failings, revealing unexpected issues.
2. Hardcoded Configurations
My codebase contains hardcoded constants like:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
Instead of using separate configuration files or environment variables, configurations are embedded directly. Updating any parameter necessitates a redeployment but allows for quick tracking through Git history. I’ve found that altering configuration values has only been necessary three times in three months, making the time invested in a formal configuration service unworthy.
3. SQLite as a Production Database
Surprisingly, I’m utilizing SQLite for a multi-user
