The 3-Month Rule: A Practical Approach to Implementing Unscalable Solutions
In the tech community, the advice from Paul Graham to “do things that don’t scale” is often quoted but rarely explored in detail, especially when it comes to coding practices. Over the past eight months, while developing my AI podcast platform, I have established a straightforward framework: any unscalable solution I implement is given a three-month lifespan. After this period, it must either demonstrate its worth and be developed into a robust system or be discarded.
As engineers, we typically strive to design scalable solutions right from the outset. We become adept at crafting intricate architectures and utilizing design patterns suited for high traffic applications. However, at startups, pursuing scalability prematurely can lead to unnecessary costs and delays, especially when we are optimizing for non-existent users and hypothetical problems. My three-month rule encourages the use of simple, direct, and even imperfect code that is capable of being launched and, more importantly, provides insights into user needs.
Current Implementation Strategies and Their Benefits
1. Consolidated Operations on One Virtual Machine
All of my major components—database, web server, background jobs, and cache—operate on a single $40/month virtual machine. This setup, devoid of redundancy, involves manual backups handled locally.
The upside of this approach is that I have gained invaluable insights regarding my actual resource consumption in just two months, insights that would have otherwise required extensive documentation. It turns out my “AI-heavy” platform peeks at around 4GB of RAM usage. Had I gone ahead with a more complex Kubernetes arrangement, I would have been managing numerous idle containers.
When the system crashes—which has happened twice—I receive genuine data on the points of failure. And, interestingly, it’s never the components I initially anticipated.
2. Directly Hardcoded Configuration Values
Instead of utilizing configuration files or environment variables, I have implemented hardcoded constants across my codebase:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
This decision may seem counterintuitive, but the hidden benefit lies in the simplicity it affords. I can easily search and locate any configuration value throughout my entire codebase in mere seconds. Each adjustment to pricing is recorded in my Git history and undergoes code review (albeit by myself).
Creating a configuration service could
