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
