The 3-Month Experiment: My Practical Approach to Building What Doesn’t Scale
In the startup world, the advice of renowned tech entrepreneur Paul Graham often echoes: “Do things that don’t scale.” While this mantra is well understood, applying it in the realm of software development can be a daunting task. Over the past eight months of developing my AI podcast platform, I’ve pioneered a straightforward framework known as the 3-Month Rule. This principle dictates that any non-scalable solution gets a three-month evaluation period after which it must either prove its worth and become a robust component of the platform or be discarded entirely.
The startup Engineer’s Dilemma: Scalability vs. Reality
As engineers, we often find ourselves heavily influenced by the need to create scalable systems right from the outset. The allure of sophisticated design patterns, microservices, and the latest in distributed systems can be strong. However, in the environment of a startup, focusing exclusively on these ideals can lead to wasted resources and excessive procrastination. Instead of optimizing for non-existent users and hypothetical issues, my 3-Month Rule compels me to write straightforward, sometimes “messy,” code that is deployable and illuminates the true needs of my users.
Current Infrastructure Choices: Insights Driven by Simplicity
1. Consolidation on a Single Virtual Machine
All essential components of my application—including the database, web server, and job queuing—are hosted on a single $40/month virtual machine. This setup, devoid of redundancy and requiring manual backups, has proven smarter than it may initially appear. In just two months, I’ve garnered insights into my actual resource requirements, discovering that my platform’s peak usage hovers around 4GB of RAM. Had I gone down the Kubernetes route, I would have wasted time managing a complex setup for a service that was not yet burdened by load.
2. Hardcoded Configurations
Instead of delving into complex configuration files or environment variables, I’ve opted for hardcoded constants throughout my code. This approach allows me to swiftly search for any configuration value, and every change is tracked through git history. In the past three months, I’ve made just three modifications, which means minimal redeployment effort compared to the hundreds of hours it would have taken to engineer a proper configuration service.
3. SQLite in a Multi-User Environment
Surprisingly, I chose to utilize SQLite for my database needs. With a mere 47MB database comfortably handling
