Embracing the Unscalable: My 3-Month Experimentation Framework
In the world of tech startups, the mantra of “doing things that don’t scale” popularized by Paul Graham is widely recognized, yet seldom discussed in the context of practical implementation—especially when it comes to coding. Over the past eight months while developing my AI podcast platform, I’ve adopted a straightforward framework that I call the “3-Month Rule.” This approach allows me to experiment with unscalable solutions for three months; after that, each solution is assessed for its value. It either becomes fully developed or gets discarded.
As engineers, we’re often conditioned to prioritize scalable solutions—think complex architectures, microservices, and distributed systems. But this line of thinking may not serve the agile and resource-constrained environment of a startup. Spending time optimizing for non-existent users or hypothetical problems can merely delay progress. My rule encourages me to deploy straightforward, sometimes imperfect, code that actually works while providing genuine insights into user needs.
Strategic Infrastructure Choices: My Hacks That Work
1. Utilizing a Single Virtual Machine
I host everything—my database, web server, background jobs, and Redis—on one $40/month virtual machine. This setup lacks redundancy and involves manually backing up data to my local system.
Why is this approach advantageous? In just two months, I’ve gained invaluable insights into my resource requirements that far exceed anything a formal capacity plan could provide. I discovered that my platform’s peak demand is around 4GB of RAM. The Kubernetes architecture I initially considered would have been a waste, managing empty containers.
When system crashes occur (and they have happened twice), I receive clear data on actual failures—often surprising insights that challenge my assumptions.
2. Hardcoded Configurations
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
I avoid complex configuration files and environment variables, opting instead for hardcoded constants. This means redeploying the application for changes, but there’s an unexpected advantage: I can quickly search my entire codebase for any configuration value and track every change in Git. Over three months, I’ve modified configurations just three times, saving significant engineering time in the process.
3. SQLite in Production
Yes, I am using SQLite for a multi-user web application, with a database size of just
