Embracing the 3-Month Rule: A Pragmatic Approach to Development in Startups
In the world of startups, the advice from Paul Graham resonates loud and clear: “Do things that don’t scale.” However, few discuss the practical steps for applying this principle in the realm of coding. After dedicating eight months to creating my AI podcast platform, I’ve developed a unique approach to navigating the challenges of scalability, which I refer to as the “3-Month Rule.”
Understanding the 3-Month Rule
Typically, as engineers, we’re trained to think big right from the start. We often dream of scalable solutions, leveraging design patterns, microservices, and distributed systems to accommodate millions of users. However, this mindset can lead to inefficient practices, particularly in a startup environment where resources may be limited and the actual user base unknown.
My rule of thumb? Each non-scalable experiment has a lifespan of only three months. If an idea demonstrates its worth within this timeframe, we refine and properly build it out. If it doesn’t prove its value? Simple—it’s time to let it go.
This approach compels me to experiment with straightforward, albeit “messy,” code that allows for rapid deployment and genuine user feedback. Here are my current strategies that, while seemingly unorthodox, have proven to be valuable for my development process:
1. Unified Hosting on a Single VM
For just $40 a month, everything from my database to background jobs runs on one virtual machine, with no redundancy or automatic backups. While this may seem like a reckless approach, it has provided invaluable insights into my actual resource usage. I’ve discovered that my platform’s maximum RAM usage peaks at just 4GB, revealing the futility of the complex Kubernetes setup I nearly implemented. Each crash grants me real-world data, often surprising me about what truly fails.
2. Hardcoded Configurations for Simplicity
I utilize hardcoded constants throughout my codebase, avoiding the complexity of separate configuration files or environment variables. While this means a manual redeployment is necessary for every change, it empowers me to quickly track changes through Git history and easily review updates. The time saved—15 minutes of redeployment compared to potentially 40 hours of engineering time to develop a configuration service—speaks volumes about the efficiency of this approach.
3. Production Use of SQLite
Yes, my multi-user application operates on SQLite, with a database size of only 47
