Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions in Code
In the tech world, you’re likely familiar with Paul Graham’s popular advice: “Do things that don’t scale.” While this philosophy is well-known, implementing it within the realm of coding can often be overlooked. Having spent the past eight months developing an AI podcast platform, I’ve devised a practical framework: every hack that doesn’t scale gets a lifespan of three months. At the end of this period, it either earns its place through proven effectiveness or is set aside.
As engineers, we often aim for scalability right from the outset. We dream of design patterns, microservices, and distributed systems capable of accommodating millions of users. This mindset, however, is more fitting for larger companies. In the startup arena, striving for scalability too early can often feel like spending valuable time optimizing for a user base that doesn’t even exist yet.
The three-month rule compels me to write straightforward, albeit imperfect, code that is deployable and informative in terms of user needs. Here’s a look at some of my current infrastructure choices, which may appear unconventional yet have proven to be effective.
1. Consolidation on a Single VM
I’ve opted to run my database, web server, background jobs, and caching all on a single $40/month virtual machine, foregoing redundancy and relying on manual backups. The brilliance of this approach is that it provides insight into my resource requirements more effectively than any capacity-planning document ever could. I discovered that my AI-driven platform peaks at 4GB RAM, indicating that my potential Kubernetes setup would have involved maintaining unused containers. When failures occur (and they have), I receive invaluable data on the actual causes, which are rarely what I anticipated.
2. Hardcoded Configurations
Rather than managing configuration files or using environment variables, I utilize hardcoded constants throughout my codebase. Adjusting values requires redeployment, but this approach offers the advantage of swift searches and editing in my code. With only three configuration changes in three months, the time spent redeploying (a mere 15 minutes) drastically outweighs the lengthy setup that would have been needed for a config service.
3. Utilizing SQLite in Production
Yes, I’ve chosen to run SQLite for a web application with multiple users. With a database size of just 47MB, it handles 50 concurrent users effortlessly. This experience revealed that my access
