The 3-Month Rule: A Tactical Approach to Embracing Non-Scalable Engineering
In the world of startups, the conventional wisdom often echoes the mantra of Paul Graham: “Do things that don’t scale.” While this advice is widely recognized, few delve into how to practically apply it in the realm of software development.
Over the past eight months, while developing my AI podcast platform, I’ve devised a straightforward yet effective framework: each non-scalable hack I implement is allocated a lifespan of three months. After this period, I assess whether it has demonstrated its worth and warrants a more robust solution, or whether it’s time to retire it.
As engineers, there’s a tendency to gravitate towards scalable architectures from the outset—think intricate design patterns, microservices, and distributed systems optimized for vast user bases. However, this approach is often more aligned with larger organizations than with startups.
In the early stages of a startup, prioritizing scalable solutions can lead to costly delays. You’re investing resources in optimizing for a user base that might not even exist. My three-month rule compels me to create simple and straightforward code that can be swiftly deployed, enabling me to gather real insights about my users’ actual needs.
Some of My Current Infrastructure Strategies and Their Hidden Advantages
1. Consolidating Everything on a Single VM
All components—database, web server, background jobs, and caching—are running on one $40/month virtual machine. There’s no redundancy and I’m handling backups manually.
Why is this an intelligent choice rather than a reckless one? I’ve swiftly gained insight into my resource requirements in a way that extensive planning documents could never reveal. For instance, it turns out my “AI-heavy” application peaks at just 4GB of RAM. The complex Kubernetes setup I considered would have resulted in managing idle containers rather than addressing my actual needs.
Whenever the system crashes (which has happened twice), I receive invaluable information about the causes. Interestingly, the failures are never what I anticipated.
2. Hardcoding Configuration Values
My configuration settings are straightforward constants sprinkled throughout my codebase:
plaintext
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
There are no external configuration files or environment variables—just hardcoded values. This means that any adjustment requires a redeployment.
The advantages? I can quickly search for
