Implementing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions
When it comes to entrepreneurship and startup development, one piece of advice that often surfaces is Paul Graham’s famous guidance: “Do things that don’t scale.” However, the challenge lies in translating this principle into tangible coding practices.
After spending the past eight months developing my AI podcast platform, I’ve devised a straightforward framework that revolves around one key tenet: every non-scalable solution gets a lifespan of three months. At the end of this period, we either transition it into a scalable, robust solution or phase it out entirely.
As engineers, we are conditioned to seek scalable solutions from the get-go, utilizing sophisticated design patterns and modular architectures. However, this mindset often distracts us from the realities of a startup environment, where scalability can turn into costly delays, solving problems that may never arise. By adhering to my 3-month rule, I’m encouraged to adopt simpler, even “imperfect” coding practices that allow me to deliver quickly and learn what truly benefits my users.
My Innovative Hacks and Their Hidden Benefits
1. Consolidating Everything on a Single Virtual Machine
Currently, my database, web server, and background jobs all operate on one $40/month virtual machine, with no redundancy and manual backups. While this setup may seem reckless, it provides invaluable insights into my resource requirements. I’ve learned that my platform operates optimally with just 4GB of RAM, and the complex Kubernetes architecture I almost implemented would have unnecessarily managed empty containers. Each crash offers data that reveals unforeseen issues, allowing me to adapt rapidly.
2. Embracing Hardcoded Configurations
Instead of relying on configuration files or environment variables, I’ve opted for hardcoded constants throughout my codebase. This might seem inefficient, but I can quickly search for any configuration value, ensuring all changes are tracked in version control. Over the last three months, I made minimal changes, which meant minimal redeployment time—15 minutes versus the potential 40 hours it would have taken to create a configuration service.
3. Running SQLite in a Production Environment
Yes, I am using SQLite for a multi-user application, and my entire database size is just 47MB, managing up to 50 concurrent users seamlessly. My analysis shows that access patterns are 95% read-heavy and only 5% write-heavy, making SQLite an ideal fit. Had I opted for a more
One Comment
This post offers a refreshingly pragmatic perspective on balancing speed and scalability in startup development. The 3-month rule acts as a disciplined sandbox, allowing founders and engineers to experiment rapidly without over-engineering initially. I appreciate how this approach emphasizes learning fast and iterating based on real user feedback—something crucial during early-stage MVPs.
The examples, like consolidating everything on a single VM and using hardcoded configs, highlight that sometimes simplicity and agility trump perfection. These tactics reduce time-to-market and provide valuable insights that inform future scalable solutions. The use of SQLite in a multi-user environment is also a compelling reminder that database choice should be driven by actual usage patterns rather than convention.
Overall, this framework encourages a mindset shift: prioritize rapid iteration and validation in the short term, and let the insights gathered guide sustainable scaling strategies. It’s a compelling reminder that “doing things that don’t scale” can be structured and intentional, provided there’s a clear plan to transition towards scalability when the timing is right.