The Three-Month Framework: A Pragmatic Approach to Building Unscalable Solutions
In the startup world, you often hear Paul Graham’s famous mantra: “Do things that don’t scale.” While this is great advice, the challenge lies in understanding how to apply it effectively, especially in software development. After eight months of working on my AI podcast platform, I’ve adopted a straightforward principle: any temporary, non-scalable solution I implement gets a lifespan of three months. If it proves its value within that time, it transitions into a more robust setup; otherwise, it is phased out.
Why the Three-Month Rule Works
As engineers, many of us are conditioned to think big from day one—creating scalable solutions with sophisticated architectures like microservices and distributed systems. However, in the context of a startup, to focus solely on scalability can often mean delaying progress for problems that may not even exist. My three-month framework encourages me to embrace simpler, more straightforward code that not only gets deployed but also helps uncover the genuine needs of my users.
My Current Infrastructure Strategies and Their Benefits
1. A Single VM for Everything
I run my entire platform—database, web server, background tasks, and caching—on a single $40/month virtual machine without redundancy or complex setups. While it may seem reckless, this simplicity has taught me invaluable lessons about my resource needs. For instance, my platform, which I initially anticipated would be data-intensive, only peaks at 4GB of RAM. The intricate Kubernetes architecture I was considering would have simply managed idle containers. When downtime occurs (and it has twice), I gain insights into real issues rather than hypothetical ones.
2. Hardcoded Values for Configuration
In my code, configurations are directly embedded as constants, such as pricing tiers and user limits. While it may be unconventional, it allows me to quickly search for values across the codebase and track changes via Git history. In the three months I’ve been using this method, I’ve modified configurations only three times, which means redeploying them was a matter of minutes instead of days of development effort spent on a dedicated configuration service.
3. SQLite for Production Use
Yes, I’m utilizing SQLite for a web application meant for multiple users. Despite having only a modest 47MB database, it manages around 50 active users effortlessly. This approach revealed that my usage was heavily skewed toward reads rather than writes, making SQLite a perfect fit. Rather than grappling with
