Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Development
In the realm of startup culture, one piece of advice reigns supreme: “Do things that don’t scale,” a mantra popularized by Paul Graham. However, while the concept is widely recognized, the practical application in the coding world often goes unexplored.
Over the past eight months, as I’ve worked to develop my AI podcasting platform, I’ve created a unique framework that focuses on a three-month lifespan for any unscalable hack. This approach mandates that after three months, each solution must either validate its worthiness and be properly refined or be discarded altogether.
The Challenge of Engineer-Driven Scaling
As engineers, we are conditioned to build robust, scalable systems from the outset. Concepts like microservices, distributed systems, and sophisticated architectures dominate our thinking. Yet, when you’re running a startup, striving for scalability from day one can lead to costly delays, as we often optimize for potential users before they even exist. My three-month rule encourages me to prioritize practical, straightforward solutions that lead to actual user insights.
Current Infrastructure: Smart Hacks That Work
Here are some of the low-tech strategies I’ve implemented, which I firmly believe are not just simplistic, but strategically intelligent:
1. Single VM Architecture
I host everything—from the database to the web server—on a single $40/month virtual machine. This means no redundancy and manual backups. Surprisingly, this has provided me with critical insights regarding my resource needs. My initial assumption of needing a complex Kubernetes setup proved unfounded, as my platform operates smoothly with just 4GB of RAM. This scheme has taught me how to react to real crashes rather than hypothetical scenarios.
2. Direct Configuration Management
With everything hardcoded—from pricing tiers to user limits—changing configurations necessitates a redeployment. The beauty of this method is that it simplifies tracking and updating values. I can quickly search through my entire codebase for any constant, ensuring that modifications are both straightforward and transparent. Spending a modest 15 minutes redeploying is far more efficient than investing a week in setting up a configuration service that I rarely need.
3. SQLite as the Chosen Database
Yes, I made the unconventional decision to use SQLite for a multi-user web application. With a database size of just 47MB, it handles 50 concurrent users easily. This setup has illuminated my data access patterns, revealing they’re overwhelmingly read-intensive.
