Embracing the 3-Month Experiment: A Framework for Unscalable Solutions in Tech
In the ever-evolving landscape of tech, one piece of wisdom rings true: “Do things that don’t scale,” as advised by Paul Graham. However, the application of this principle within the coding realm remains less explored. Drawing on my eight-month experience developing an AI podcast platform, I’ve established a straightforward framework: any unscalable technique is assigned a lifespan of three months. If it demonstrates its worth during that time, it gets the formal treatment it deserves; if not, it’s time to move on.
As engineers, we’re often groomed to prioritize scalability from the onset, focusing on design patterns, microservices, and distributed systems capable of handling millions of users. While this big-business mentality can be tempting, it can also be a trap for startups, where focusing on scalability too early can lead to costly procrastination. Instead of preparing for users who may never arrive, my 3-month rule encourages me to write straightforward, albeit “imperfect,” code that can be deployed and which reveals actionable insights about user needs.
Innovating with Current Infrastructure Hacks
Here are some of the pragmatic, yet seemingly unconventional, strategies I’ve implemented that have proven invaluable:
1. Running All Services on a Single VM
I manage my entire stack—database, web server, background jobs, and caching—on a singular $40/month virtual machine. While this setup lacks redundancy and relies on manual local backups, it has provided far greater insight into my resource needs than traditional capacity planning documentation ever could. For instance, I’ve found that my “AI-heavy” platform consistently peaks at just 4GB of RAM. The complex Kubernetes architecture I nearly implemented would have led me to manage idle containers instead.
Each crash (and there have been two) has yielded real data about failure points. The results are enlightening—issues arise in unexpected places.
2. Hardcoded Configuration Management
Configuration values like pricing tiers and user caps are hardcoded directly in the source files. This means any changes necessitate a redeployment, but it’s a blessing in disguise. The ability to perform a quick search through my codebase for any configuration value has become invaluable. With only three changes in three months, I’ve saved countless hours that would have been devoted to building and maintaining a configuration service.
3. Production-Level SQLite Usage
Surprisingly, I’ve opted for SQLite in a multi
One Comment
This post offers a compelling reminder that practical, short-term experimentation can be incredibly valuable—especially for startups and small teams. The 3-month rule acts as a disciplined yet flexible framework to rapidly test unscalable ideas without over-investing in early stages.
It’s interesting how your approach—such as running everything on a single VM and hardcoding configurations—prioritizes speed and learning over perfect architecture. These strategies cut through the noise of premature optimization, allowing you to focus on validating core hypotheses quickly.
One aspect worth exploring further is how to balance the benefits of these unscalable tactics with a plan for eventual scalability, should the product succeed. Perhaps, as your platform matures, you can transition from these hacks to more scalable solutions incrementally, guided by clear metrics acquired during these short cycles.
Overall, your framework underscores the importance of agility and real-world experimentation—a mindset that can often lead to better product-market fit and sustainable growth. Thanks for sharing such actionable insights!