The 3-Month Experiment: My Technical Approach to Non-Scalable Solutions
In the tech world, the mantra “Do things that don’t scale,” popularized by Paul Graham, is often echoed but not always practically applied, particularly when it comes to coding. After spending eight months developing my AI podcast platform, I’ve crafted a straightforward framework that revolves around an intriguing concept: any unscalable solution I implement is given just three months to prove its worth. If it doesn’t demonstrate clear value in that time, it’s time to move on.
As engineers, we typically emphasize building scalable solutions from the outset. We dive into complex design patterns, microservices architectures, and distributed systems—fancy frameworks designed to support massive user bases. However, in the startup realm, focusing solely on scalability can lead to wasting resources. We often find ourselves catering to potential users who may never materialize and addressing problems that may never arise. My 3-month rule compels me to write straightforward, albeit “imperfect,” code that can be deployed quickly and helps reveal the true needs of my users.
Here are some of the current hacks in my infrastructure that may seem unconventional but serve a purpose:
1. Unified Virtual Machine Architecture
I operate my entire setup, including the database, web server, and background jobs, on a single $40/month virtual machine (VM). While this setup has zero redundancy and relies on manual backups, it has provided valuable insights about my actual resource requirements over the past two months. I discovered that my “AI-heavy” platform peaks at just 4GB of RAM, which could have turned into an unnecessary Kubernetes configuration. Each crash (two so far)提供s me clear data on real weaknesses—issues I would have otherwise overlooked.
2. Hardcoded Configuration
Instead of using environment variables or extensive configuration files, I have opted to hardcode settings directly into my application. Constants like:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
This might seem impractical, but it allows for rapid access to configuration values across the codebase. Modifying values requires only a brief redeployment—taking around 15 minutes—compared to the extensive time involved in building a formal configuration service, which I estimated at roughly 40 hours of engineering effort.
3. SQLite as a Production Database
Surprisingly, I’m relying on SQLite
One Comment
This post offers a refreshing perspective on balancing rapid experimentation with practical engineering decisions, especially in the early stages of a startup. I appreciate the emphasis on time-bound, non-scalable solutions as a means to validate assumptions quickly.
The 3-month rule is a pragmatic approach—by setting clear boundaries for unscalable solutions, it helps avoid the trap of over-engineering before truly understanding user needs and platform demands. Your example of running everything on a single VM is a testament to how real-world insights can inform smarter scaling decisions later.
Additionally, the choice of hardcoded configurations and SQLite for initial deployments highlights the importance of prioritizing speed and flexibility over perfect architecture early on. These adaptations allow for rapid iteration, which is crucial in testing hypotheses and iterating based on real feedback.
One thought I’d add is the potential for intentionally designing these initial solutions with planned, quick endpoints for easy replacement or scaling once validated. This way, you can keep your initial hacky setup while maintaining a clear roadmap for transitioning to more robust infrastructure as needed.
Overall, your framework underscores that sometimes, doing things that don’t scale upfront can save time and resources in the long run—allowing founders and engineers to focus on product-market fit before investing heavily in scalability.