Embracing the 3-Month Rule: A Practical Approach to Unscalable Solutions in Tech
In the entrepreneurial tech world, one well-known piece of advice from Paul Graham resonates deeply: “Do things that don’t scale.” While this guidance is often quoted, the conversation rarely delves into how to practically implement it, especially in coding. After eight months of developing my AI podcast platform, I’ve created a straightforward framework that I adhere to—any unscalable solution receives a mere three months before I decide whether to enhance it or discontinue it altogether.
As developers, we’re often conditioned to construct scalable solutions from the very outset. We talk about design patterns, microservices, and distributed systems—all essential elements for accommodating vast user bases. However, this mentality often leads startups astray, making them invest time and resources into optimizations for users who aren’t even in the pipeline yet. My three-month rule compels me to produce straightforward, albeit ‘messy,’ code that actually gets deployed, allowing me to learn what my users genuinely require.
Current Infrastructure Hacks: Lessons Learned
1. Consolidated Operations on a Single VM
All elements of my platform—database, web server, background jobs, and Redis—operate on a single $40/month virtual machine (VM). There’s zero redundancy and I manually back up everything to my local device.
Why is this approach innovative? Within two months, I have gained insights into my actual resource usage that no planning document could provide. My once presumed “AI-heavy” system only ever peaks at around 4GB of RAM. The complicated Kubernetes framework I almost implemented would have resulted in managing empty containers. Each time the system crashes (which has occurred twice), I gain insights into actual failure points—insights that often surprise me.
2. Hardcoded Configurations for Simplicity
Rather than leveraging configuration files or environment variables, I’ve opted to define constants directly in my code. Adjusting these values necessitates a redeployment, which occurs infrequently—only three times in three months.
The beauty of this approach lies in its transparency; I can quickly search my entire codebase for any configuration value. By tracking price changes in Git, I keep a record that’s easier to manage than building a configuration service, which would consume a week of development time. Instead, those 15 minutes spent redeploying is a small price for effective efficiency.
3. SQLite: An Unconventional Choice for Production
My
