The 3-Month Rule: A Framework for Developing Unscalable Solutions
In the startup landscape, the well-known mantra from Paul Graham—”Do things that don’t scale”—is often cited as foundational advice. However, the practical application of this principle, particularly in coding, can be elusive. After spending eight months creating my AI podcast platform, I have adopted a straightforward framework: any unscalable hack gets a trial period of three months. If it proves its worth during that time, it will be properly refined; otherwise, it will be discarded.
As engineers, we’ve been trained to prioritize scalable solutions from the outset. The focus on sophisticated architecture, such as microservices and distributed systems, caters to businesses anticipating large-scale user engagement. Yet, in the startup phase, investing in scalability can often become counterproductive, as we may be addressing problems that do not yet exist. My three-month rule compels me to deploy simple, effective code that can be tested in real-time, allowing me to glean insights about my users’ needs.
Clever Infrastructure Decisions That Deliver Insights
1. One VM to Rule Them All
Currently, my entire architecture—database, web server, background tasks, and Redis—resides on a single virtual machine costing $40 per month. While this setup sacrifices redundancy and relies on manual backups, the advantages are significant. Over the past two months, I have gained insights regarding my actual resource consumption that no capacity planning could provide, such as discovering that my platform’s peak usage only requires 4GB of RAM. The complex Kubernetes environment I almost pursued would have meant managing emptiness instead of genuine usage.
Following crashes (which have occurred twice), I have received concrete data on what actually fails—revealing factors I never anticipated.
2. Hardcoded Configurations and Their Benefits
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
Instead of using configuration files or environment variables, I utilize hardcoded constants throughout my code. This means any adjustment necessitates a redeployment; however, the benefits of this method are significant. My ability to quickly grep for configuration values has made tracking changes simpler, allowing for more streamlined oversight through version control. Given that I’ve updated these values only three times in three months, the 15 minutes spent redeploying is a far cry from
