Embracing the Unscalable: My 3-Month Experimentation Framework

In the entrepreneurial world, advice from influential figures like Paul Graham to “do things that don’t scale” often circulates, yet the nuances of translating this wisdom into practical coding strategies remain underexplored. After dedicating eight months to building my AI podcast platform, I’ve developed a straightforward yet effective framework: every unscalable hack is assigned a three-month lifespan. After this period, these hacks either demonstrate their worth and are refined into robust solutions, or they are discarded.

As engineers, we are typically conditioned to pursue scalable solutions from the outset—considerations like design patterns, microservices, and distributed systems often dominate our thinking. However, such an approach can be an exercise in costly procrastination, especially in a startup environment. That’s where my three-month rule comes into play, compelling me to produce simpler, albeit less elegant, code that can be shipped quickly and offers real insights into user needs.

Current Infrastructure Hacks and Their Hidden Benefits

1. Unified Operations on a Single VM

I’ve consolidated my database, web server, background jobs, and Redis functions onto a single $40/month virtual machine. This setup lacks redundancy and relies on manual backups to my local device. The benefits? Within just two months, I’ve gained invaluable insights into my actual resource demands—my platform realizes peak usage at around 4GB of RAM. A complex Kubernetes structure would have meant managing unused containers, while each crash teaches me about the aspects to focus on.

2. Configuration Hardcoding

My project is devoid of config files and environment variables. Instead, I use hardcoded constants like:

PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"

This approach may seem simplistic, but it enables me to quickly search my codebase for configuration values. Any changes to pricing or variables are tracked in Git history and thoroughly reviewed—even if just by me. Considering I’ve only adjusted these constants three times in as many months, the slight inconvenience of redeploying is minimal compared to the time saved on complex configurations.

3. Employing SQLite in Production

Surprisingly, I’m using SQLite for a multi-user application with a database size of just 47MB, managing 50 concurrent users effortlessly. This choice helped me identify that my