Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Solutions
In the world of startups, the well-known advice from Paul Graham—”Do things that don’t scale”—is often easier said than done, especially when it comes to coding practices. After dedicating the last eight months to developing my AI podcast platform, I’ve adopted a simple yet effective framework that allows me to experiment with unscalable solutions: each tactic is given a three-month lifespan. If it’s proven to be valuable within that time frame, I’ll refine it; otherwise, it’s time to move on.
As engineers, we’re often conditioned to aim for scalable solutions right from the start. We tend to focus on complex architectures like microservices and distributed systems, which can effectively handle millions of users. However, this thinking is often more applicable to established companies rather than startups where resources are limited and immediate user needs are paramount.
In fact, pursuing scalability too early can lead to wasted resources, as we tend to optimize for future users that may never materialize. My three-month approach pushes me to create straightforward, even “suboptimal” code that delivers tangible results and reveals genuine user needs.
Current Infrastructure Experiments: Practical Takeaways
1. Consolidation into a Single Virtual Machine
Currently, my web server, database, background jobs, and caching—all coexist on a single $40/month virtual machine. While this approach lacks redundancy and employs manual backups to my local machine, it has been a tremendous learning experience. In just two months, I’ve gained insights into my actual resource needs that no extensive planning document could have provided. For example, I discovered that my platform, despite its AI-centric focus, peaks at just 4GB of RAM. A complex Kubernetes setup I considered would have been managing idle resources instead.
Crashes have occurred (twice, to be precise), but each one supplied valuable data regarding system vulnerabilities and weaknesses.
2. Hardcoded Configuration Values
Throughout my code, you’ll find constants like:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
While some may scoff at the absence of configuration files or environment variables, this simplicity allows me to quickly search my entire codebase for any configuration value. Any price alteration is tracked via Git history, and changes are easily reviewed.
