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