The 3-Month Rule: My Approach to Testing Non-Scalable Solutions in Tech
In the startup world, the common wisdom from Paul Graham that encourages us to “do things that don’t scale” is often easier said than followed, especially in the realm of coding. After dedicating eight months to developing my AI podcast platform, I’ve adopted a straightforward framework: any unscalable solution gets a three-month trial period. At the end of that timeframe, we either integrate it more robustly if it proves valuable, or we discontinue it.
As engineers, we typically aim for scalable solutions from the outset, embracing design patterns and microservices that can accommodate millions of users. However, in a startup environment, pursuing scalability too early can lead to unnecessary complexity and wasted resources. My three-month guideline compels me to create simple, straightforward code that helps me understand user needs more effectively and expedites the shipping process.
My Current Infrastructure Techniques and Their Unexpected Benefits
1. Consolidated on a Single VM
I’ve opted to run my entire application—database, web server, background jobs, and Redis—on a single $40/month virtual machine, foregoing redundancy for simplicity. While this might seem reckless, I’ve gained far more insight into my resource requirements in just two months than I would have from extensive capacity planning. For instance, my platform’s peak usage requires only 4GB of RAM, revealing that the complex Kubernetes infrastructure I nearly implemented would have managed numerous empty containers.
Each time my setup crashes (which has happened twice), I collect real-time data on the issues at play, and they never align with my expectations.
2. Static Configuration Throughout
I manage configuration settings directly in my code:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
There are no separate config files or environment variables; just hardcoded constants. This might sound impractical, but it provides swift access to any configuration value via a simple search. With every change fully documented in my git history, even though I’m essentially reviewing my own pull requests, it offers transparency and accountability.
Setting up a configuration service would have taken a week, yet I’ve only modified these values three times in three months. That equates to a mere 15 minutes for redeployments versus 40 hours of engineering work.
