Embracing the 3-Month Rule: A Pragmatic Approach to Development
In the world of software development, the wisdom of Paul Graham resonates: “Do things that don’t scale.” However, practical implementation of this advice, especially in coding, is seldom discussed. After eight months of building my AI podcast platform, I have devised a straightforward framework: any unscalable workaround receives a lifespan of just three months. After this period, it either demonstrates its worth and is fully developed, or it’s removed from the equation.
As engineers, we tend to gravitate towards scalable solutions right from the outset. We often talk about design patterns, microservices, and distributed systems—architectures designed to manage millions of users. This mindset is ideal for larger organizations, but in a startup environment, such scalable solutions can become a costly form of procrastination. We often find ourselves optimizing for hypothetical users, tackling problems that may never arise. My 3-month rule compels me to create straightforward, even “bad,” code that actually gets implemented, allowing me to understand my users’ genuine needs.
Current Structural Experiments and Their Unexpected Benefits
1. Centralized Operations on a Single Virtual Machine
My entire stack—database, web server, background jobs, and caching—runs on one $40/month virtual machine. It may lack redundancy and rely on manual local backups, but this setup has proven enlightening. In just two months, I’ve gained more insights into my resource requirements than any meticulous capacity planning could provide. My “AI-centric” platform only peaks at 4GB of RAM. The complex Kubernetes architecture I was considering would have only facilitated the management of idle containers. Each crash (which has occurred twice) has provided valuable information about what actually fails—spoiler alert: it’s never what I anticipated.
2. Hardcoded Configurations for Simplicity
Rather than employing configuration files or environment variables, I’ve opted for hardcoded constants throughout my codebase. This means changing a value prompts a redeployment, but it also allows me to quickly search for any configuration using simple commands. With just three configuration changes in three months, I’ve saved considerable development time—15 minutes of redeployment versus an estimated 40 hours spent constructing a configuration management system.
3. Utilizing SQLite for Production
Yes, I am using SQLite in a multi-user web application. With a database size of just 47MB, it easily accommodates 50 concurrent users. This choice has unveiled
