Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Software Development
In the startup world, it’s common to hear the advice from renowned entrepreneur Paul Graham: “Do things that don’t scale.” However, the challenge often lies in figuring out how to apply this principle effectively in software development.
Over the past eight months, while creating my AI podcast platform, I devised a straightforward framework that I like to call the “3-Month Rule.” The idea is simple: any unscalable hack is given a trial period of three months. If it proves effective during that time, it gets the chance for proper implementation; if not, it’s out.
Rethinking Scalability
Traditionally, as engineers, we’re conditioned to create scalable solutions from the outset. Our training emphasizes the importance of design patterns, microservices, and complex architectures designed to support vast user bases. However, this mindset can often lead to unnecessary optimization efforts, especially in a startup environment where scalability might merely delay progress.
By adhering to my 3-Month Rule, I focus on writing direct, uncomplicated code that can be deployed quickly. This approach not only helps me glean insights into user needs but also allows me to learn valuable lessons on the fly.
My Infrastructure Hacks: A Learning Perspective
Here are some of the unconventional strategies I’ve implemented, which have turned out to be surprisingly effective:
1. Consolidating on a Single Virtual Machine
I opted to run my database, web server, background jobs, and caching all on a single $40/month virtual machine without redundancy. While this may seem risky, the reality is that this setup has helped me gain an accurate understanding of my resource utilization. In two short months, I learned that my platform peaks at just 4GB of RAM. The complex Kubernetes architecture I once contemplated would have been overkill, merely managing empty resources.
Whenever the system crashes—which has happened twice—I gain invaluable insight into what truly fails, which frequently isn’t what I expected.
2. Hardcoded Values for Configuration
Instead of utilizing complex configuration files or environment variables, I’ve opted for hardcoded constants throughout my code. This method simplifies deployments; any change necessitates a redeployment but allows for quick tracking and understanding of all value adjustments through version history. Over the past three months, I’ve only needed to make minor adjustments, making this technique vastly more time-efficient than building a separate configuration management service.
