The 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions in Development
In the fast-paced world of startups, the mantra “do things that don’t scale” is a popular slogan among entrepreneurs. While Paul Graham’s advice rings true, the application of this principle within the realm of coding is less frequently discussed. After spending eight months developing my AI podcast platform, I devised a straightforward framework that guides my approach: any hack that doesn’t scale gets a trial period of just three months. If it proves its worth, I will enhance it; if not, it gets discarded.
As software engineers, we often fall into the trap of designing for scalability from the outset. We invest time and energy into sophisticated architectures such as microservices and distributed systems, which are ideal for handling millions of users. However, in a startup environment, prioritizing scalability early on can lead to costly delays and misguided efforts directed at hypothetical challenges. This three-month rule compels me to write simple, straightforward code that can be deployed quickly and reflects the actual needs of my users.
Insights and Infrastructure Hacks: Smart Choices in Coding
1. Consolidating Everything on a Single Virtual Machine
I operate my entire platform—database, web server, background jobs, and Redis—on a single $40/month virtual machine, without any redundancy. While backup procedures are manual, this setup has provided invaluable insights into my actual resource consumption in just two months. For instance, I discovered my platform, which I had thought would require extensive resources, actually peaks at just 4GB of RAM. The intricate Kubernetes configuration I was considering would have led to unnecessary complexity and management of unused containers. When the system inevitably encounters issues (which has happened a couple of times), I gather real data about the specifics of the failure rather than relying on assumptions.
2. Utilizing Hardcoded Configuration
Instead of complicating matters with configuration files or environment variables, I use hardcoded constants throughout my codebase. Adjusting any value involves a straightforward redeployment, which is manageable as I’ve only made changes three times in three months. This approach allows me to efficiently track every adjustment in my version control history, making it easy to reference past configurations.
3. Choosing SQLite for Production
I’ve opted to run SQLite for my multi-user web app, with the entire database occupying just 47MB. This solution comfortably accommodates up to 50 concurrent users, demonstrating that my application’s access patterns are heavily read-dominant
