Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions
In the world of startups, there is a well-known principle articulated by Paul Graham: “Do things that don’t scale.” While this mantra is often tossed around, the practical implementation of it in the technical realm is rarely discussed.
After eight months of developing my AI podcast platform, I devised a straightforward yet effective framework: every unscalable solution is given a lifespan of three months. At the end of this period, if it proves its worth, I’ll invest the time to build it properly. If not, it gets the ax.
The Dilemma of Scalability
As engineers, our training encourages us to prioritize scalable solutions right from the outset. We focus on advanced design patterns, microservices, and robust architectures tailored for handling vast user bases. However, this mindset can often be a hindrance in a startup environment, where such scalability might simply mean delayed progress. My three-month rule compels me to create straightforward, even “poorly-designed,” code that can be shipped quickly, allowing me to uncover real user needs.
Current Infrastructure: Smart Hacks That Yield Insights
1. Consolidating to a Single VM
Every component of my platform—database, web server, background jobs, and caching—operates on one $40 per month virtual machine. While this presents zero redundancy and necessitates manual backups, it’s been an invaluable learning experience. In just two months, I’ve grasped my true resource requirements better than any planning document could. My platform’s highest peak? A modest 4GB of RAM. The complex Kubernetes setup I nearly implemented would have essentially managed empty loads.
Each time the system crashes—twice so far—I gain invaluable insights into actual failure points, which are frequently unexpected.
2. Embracing Hardcoded Configuration
Consider the following constants:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
There are no configuration files or environment variables, just constants embedded throughout the code. Changing any value necessitates a redeployment, but this approach has its advantages: I can trace any configuration value across my codebase swiftly, track price adjustments through Git history, and even review updates (by myself).
Building a dedicated configuration service would demand significant time; however, I’ve
