Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Solutions in Software Development
In the world of startups, the mantra of “do things that don’t scale,” originally popularized by Paul Graham, is often repeated, but the implementation of that concept in the realm of coding is rarely discussed. After spending eight months developing my AI podcast platform, I’ve established a pragmatic framework that I call the 3-Month Rule. Under this guideline, any unscalable hack is given a three-month lifespan to demonstrate its worth. At the end of this period, it either evolves into a well-structured solution or gets discarded.
As engineers, we’ve been trained to pursue scalable solutions right from the outset. We dream in terms of microservices, distributed systems, and complex architectures that are designed to handle millions of users. However, this mindset can often be more suitable for larger companies than for startups. In reality, chasing scalability too early can lead to costly delays, optimizing for hypothetical future users while neglecting the needs of the present.
My 3-Month Rule encourages the adoption of simpler, more direct coding practices that yield tangible results and, crucially, provide insights into actual user needs.
My Current Infrastructure Hacks and Their Hidden Benefits:
1. Consolidated Operations on a Single VM
I operate everything from a single $40/month virtual machine, running my database, web server, Redis, and background jobs. Although this setup lacks redundancy and is dependent on manual backups, it has equipped me with invaluable insights into my infrastructure requirements. Within just two months, I discovered that my platform’s demand peaks at 4GB of RAM—something that a complex capacity planning approach would not have revealed.
When system crashes occur, as they have twice, I gain real data about the factors causing the issues. As it turns out, the reasons are never what I initially anticipated.
2. Hardcoded Configuration
My application currently relies on hardcoded configuration settings, with constants scattered throughout the codebase. This approach might seem primitive, but it grants me the ability to quickly track configuration changes through version control. In three months, I’ve only modified these values three times; thus, I’ve saved countless hours by avoiding the construction of a separate configuration service.
3. Leveraging SQLite in Production
For a multi-user application, I opted for SQLite, which surprisingly manages to support multiple concurrent users with ease. With a database size of just
One Comment
This is a fantastic articulation of the importance of embracing unscalable solutions as a means to quickly validate assumptions and gain real-world insights. The 3-Month Rule echoes the pragmatic philosophy that, especially in startups, speed and learning often trump premature architectural complexity.
Your example of consolidating operations on a single VM highlights the value of simplicity in surface area and ease of iteration—something that often gets overlooked in favor of “best practices.” Additionally, leveraging hardcoded configs and SQLite in production are pragmatic choices for early-stage products, enabling rapid deployment and learning without the overhead of complex infrastructure.
It’s a compelling reminder that, as engineers, we should prioritize learning and adaptability, especially in the critical early months of a project. By setting clear time frames for unscalable hacks, we create a structured way to test ideas while avoiding the trap of infinite optimization — ultimately fostering a mindset that values progress over perfection. Thanks for sharing these insights!