Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions
In the world of startups, pursuing the advice of thought leaders like Paul Graham to “do things that don’t scale” can feel daunting, especially for developers. While the concept is widely recognized, the practical application in the realm of coding often remains unaddressed.
Over the past eight months, as I have been developing my AI podcast platform, I’ve established a straightforward framework to navigate this challenge: every experimental, non-scalable hack gets a lifespan of just three months. Within this period, each solution must either demonstrate its value and be properly implemented or be discarded.
The Startup Environment: A Different Mindset
As engineers, we are instinctively drawn to design architectures that can support large-scale operations from the onset—think distributed systems, microservices, and complex design patterns aimed at managing millions of users. However, in a startup setting, the focus on scalability can sometimes morph into an exercise in avoidance, as we optimize for hypothetical users and issues that may never materialize.
By adhering to my 3-month rule, I prioritize writing straightforward, unrefined code that delivers real results. It’s this approach that unveils invaluable insights into actual user needs.
Current Infrastructure Hacks: Effective Simplicity
1. Single VM Architecture
My entire platform operates on a single virtual machine for a mere $40 per month, encompassing everything from the database to background jobs. While this setup lacks redundancy and relies on manual backups, it has provided me with deep insights into my resource requirements. In just two months, I discovered my platform’s maximum demand peaks at 4GB of RAM, thus validating that a complicated Kubernetes setup would have been a misallocation of resources.
2. Hardcoded Configuration
With values such as pricing tiers and user limits hardcoded throughout my codebase, making changes requires redeployment. While this may appear inefficient at first glance, it allows me to quickly track all adjustments over time and ensures consistent configuration throughout my application. Instead of investing a week into developing a configuration service, my deployment process remains concise and effective, allowing for swift changes when necessary.
3. SQLite for Production Use
Surprising as it may sound, I’m running a multi-user web application on SQLite, with a database size of only 47MB. The database supports up to 50 concurrent users with exceptional performance, revealing that my usage patterns consist of 95% read operations
One Comment
This is a valuable perspective on balancing pragmatism with startup agility. The 3-month rule serves as a disciplined yet flexible approach, preventing analysis paralysis and encouraging rapid iteration — key in early-stage environments. I particularly appreciate your emphasis on embracing simple infrastructure, like using a single VM and SQLite, which aligns well with the “lean startup” philosophy of validating assumptions first before scaling.
One aspect worth considering is how your framework might evolve as your platform grows. For instance, at some point, you may need to reassess the hardness of configurations or database choice to accommodate increased complexity. But the core idea — testing and validating solutions quickly, then committing or discarding — remains invaluable.
Ultimately, it’s about learning rapidly and avoiding over-engineering early on, which can drain resources and slow down progress. Your approach is a compelling reminder that sometimes, less is more, and that iterative validation builds a solid foundation for scalable growth down the line.