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
One Comment
Thanks for sharing this insightful approach! Your “3-Month Rule” is a refreshing reminder that in the early stages, practicality and speed often outweigh long-term scalability considerations. I especially appreciate your emphasis on rapid experimentation—deploying simple, unscalable solutions that provide real user insights.
The choice to use a single VM and hardcoded configurations exemplifies a lean methodology that prioritizes learning over perfection. It’s interesting how these practical hacks not only accelerate development but also reveal true resource needs and system behavior under real-world conditions.
Your experience underscores an important principle: sometimes, embracing an unscalable approach temporarily can save time, reduce complexity, and inform better scalable solutions down the line. It aligns well with the idea that doing things that don’t scale initially is a strategic investment rather than a shortcut. Looking forward to seeing how these insights evolve as your project grows!