The 3-Month Experiment: A Pragmatic Approach to Developing Non-Scalable Solutions
In the startup world, there’s a well-known principle from Paul Graham: “Do things that don’t scale.” It’s a piece of advice often shared but rarely dissected, particularly when it comes to writing code. Throughout my eight-month journey of building an AI podcast platform, I’ve adopted a practical framework to tackle this directive: every non-scalable solution is given an operational timeframe of three months. After this period, the approach either proves its worth and is refined into a robust solution, or it is phased out.
As software engineers, we often find ourselves inclined to construct scalable solutions from the outset, focusing on design patterns, microservices, and extensive systems that can handle immense user loads. While this might be typical for larger enterprises, in the startup ecosystem, overly complex solutions can lead to unnecessary delays and costs, as they primarily address problems that may not yet exist.
This is where my three-month experiment comes into play, inspiring me to embrace simpler, more straightforward code that actually gets deployed, providing vital insights into user needs.
Current Infrastructure Experiments and Their Hidden Benefits
1. Single VM Hosting
I’ve consolidated my database, web server, background jobs, and caching on a single $40/month virtual machine—without redundancy and with manual backups to my local machine.
Why is this beneficial? It has enabled me to gain a clear understanding of my resource usage in just two months, far exceeding what any complex capacity planning could provide. My AI platform, contrary to assumptions, only utilizes around 4GB of RAM at peak times. The elaborate Kubernetes system I nearly implemented would have effectively managed empty resources.
Through the occasional crashes (which have occurred twice thus far), I’ve gathered valuable data on what truly fails, and surprisingly, it’s rarely what I anticipated.
2. Hardcoded Values Instead of Config Files
plaintext
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
No environment variables or config files—just constants woven throughout my code. Any change requires a redeployment, but here’s the insight: I can effortlessly search for configuration values across the codebase, and every price adjustment is recorded in my git history, subject to review (even if it’s just my own).
Creating a configuration service
