The 3-Month Rule: A Pragmatic Approach to Non-Scalable Coding
In the tech landscape, there’s a well-known principle from Paul Graham urging developers to “do things that don’t scale.” However, implementing this concept in the world of coding isn’t often discussed. Drawing from my experience over the past eight months as I build my AI podcast platform, I’ve created a straightforward framework: each non-scalable solution gets a lifespan of just three months. Following this period, it either proves its worth and is refactored into a scalable solution or it’s phased out.
As engineers, our instinct is frequently to develop scalable solutions right from the outset. We immerse ourselves in design patterns, microservices, and distributed systems—all phenomenal for managing large user bases. However, such approaches tend to be geared more towards larger companies than startups. In a startup environment, focusing on scalability too early can lead to costly delays. Instead of preparing for a future that may not materialize, I advocate for creating simple, direct, and possibly “imperfect” code that can rapidly ship and enhance our understanding of user needs.
Current Non-Scalable Solutions: Smart Choices for Growth
1. Single Virtual Machine Architecture
Currently, my entire stack operates on a single $40/month VM, encompassing the database, web server, background processes, and caching with Redis. Admittedly, this comes with no redundancy and relies on manual backups to my local environment.
However, this setup has proven to be surprisingly advantageous. In just two months, I have gained far more insight into my resource usage than any capacity planning exercise might have provided. I discovered that my AI-driven platform rarely exceeds 4GB of RAM. Initially, I considered a complex Kubernetes architecture, but managing idle containers would have been a waste of resources.
When my system does crash (as it has twice), I gain crucial insights into what truly fails—often very different from my expectations.
2. Hardcoded Settings
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
My application runs on hardcoded constants instead of configuration files or environment variables. Changing any of these requires a redeploy.
This “flaw” actually serves a significant purpose: I can quickly search my entire codebase for any settings. Price adjustments are tracked in version history, and every configuration change undergoes a
