The 3-Month Experiment: A Pragmatic Approach to Unscalable Solutions
In the world of startup culture, advice from influential figures like Paul Graham often rings true: “Do things that don’t scale.” However, the practical application of this concept, especially in coding, is rarely discussed.
After eight months of developing my AI podcast platform, I’ve adopted a straightforward framework to manage unscalable hacks: I give each one a trial period of three months. At the end of that timeframe, I evaluate its performance. If it demonstrates value, it gets a proper infrastructure; if not, it gets scrapped.
As engineers, we often fall into the trap of envisioning scalable solutions right from the outset. We dream of design patterns, microservices, and distributed systems that can seamlessly handle millions of users. But in the startup landscape, pursuing scalability too early can be an exercise in costly procrastination. Instead of preparing for a user base that isn’t there yet, my three-month rule compels me to create straightforward, albeit imperfect, code that allows me to truly understand user needs.
Creative Unscalable Solutions That Yield Insights
1. Centralizing Functions on a Single Virtual Machine
I’m currently running my entire infrastructure on a single $40/month virtual machine, and it hosts everything—database, web server, background jobs, and even Redis. While this approach lacks redundancy and relies on manual backups, it has been tremendously enlightening. Within two months, I gained more insight into my resource requirements than any extensive capacity planning report could have provided. Surprisingly, my “AI-heavy” platform only peaks at 4GB RAM, meaning the complex Kubernetes setup I had considered would have just resulted in managing idle containers.
When my system crashes (which has occurred twice), I gather valuable real-time data about the actual points of failure—much to my surprise, the breakdowns weren’t what I anticipated.
2. Using Hardcoded Configuration
Instead of creating multiple configuration files or defining environment variables, I opt for hardcoded constants scattered throughout the code:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
This might seem limiting, but its efficiency is remarkable. I can locate any configuration value within seconds using a simple search command. Furthermore, every adjustment is logged in Git history and subjected to my own code reviews.
Building a sophisticated configuration
One Comment
Thank you for sharing this practical and thought-provoking approach. The “3-Month Rule” strikes me as an excellent method to balance experimentation with disciplined evaluation, especially in the early stages of a startup. Your emphasis on unscalable hacks as learning tools rather than permanent solutions resonates deeply; it reminds me that sometimes, the most valuable insights come from intentionally simple setups—like hosting everything on a single VM or hardcoding configs—that force us to confront actual bottlenecks and user needs firsthand.
This approach also underscores the importance of agility and learning in engineering—not just building for the future, but understanding real demand and resource use today. I believe your framework could serve as a useful template for founders and engineers alike, encouraging them to embrace the messy, unscalable experiments that uncover genuine insights about their product and infrastructure before scaling complexity. Looking forward to seeing how these experiments evolve over time!