Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Solutions in Tech Development
In the tech landscape, particularly within startups, the conventional wisdom espoused by industry leaders like Paul Graham—”Do things that don’t scale”—often goes unexamined in terms of execution. As a developer who has spent the past eight months constructing a platform for my AI podcast, I’ve devised a straightforward framework: every unscalable method is given a lifespan of three months. After this period, it either proves its worth and undergoes proper development, or it’s relegated to the sidelines.
Understanding the Challenges of Scaling
As engineers, we often feel the pressure to engineer scalable solutions from the outset, focusing on sophisticated architectural frameworks like microservices and distributed systems designed for large-scale user bases. This approach, while beneficial in big company settings, can turn into an expensive form of procrastination at a startup. By dedicating time to solutions that cater to potential users who may never materialize, we often overlook the immediate needs of our current base.
The 3-Month Rule: A Framework for Experimentation
My methodology prioritizes actionable insights derived from writing straightforward, intentionally imperfect code. Below, I detail my current infrastructure strategies and the valuable lessons they impart.
1. Centrally Located Services on a Single VM
All components—database, web services, background jobs, and caching—operate on a single $40/month virtual machine. Although this setup lacks redundancy and relies on manual backups, it’s proved incredibly insightful. In just two months, I’ve gained clarity on my platform’s actual resource requirements: it turns out that I rarely exceed 4GB of RAM. The complex Kubernetes cluster I was considering would have involved managing idle resources.
When crashes occur, they reveal specific vulnerabilities, often contrary to my predictions, allowing for data-driven improvements.
2. Simplified Hardcoded Configurations
My configuration approach is rudimentary: values like pricing tiers and user caps are hardcoded directly into the application. Altering any of these parameters entails a simple redeployment rather than a complicated configuration overhaul. This streamlined method allows for quick searches across my codebase, tracking changes effortlessly via version control.
Over the past three months, I’ve only adjusted these constants a mere three times, illustrating that extensive setups can frequently be more cumbersome than beneficial.
3. Utilizing SQLite for Production Environments
Remarkably, I’ve integrated SQLite into my multi-user web application—my database
