Embracing the 3-Month Rule: A Practical Approach to Unscalable Solutions in Tech
In the world of technology and entrepreneurial ventures, there’s a widely recognized piece of advice from Paul Graham: “Do things that don’t scale.” However, a common gap in knowledge arises when it comes to executing this principle in the realm of coding.
Having dedicated eight months to the development of my AI podcast platform, I’ve devised an effective framework that revolves around the idea of giving every non-scalable hack a limited lifespan of three months. By the end of this period, each solution must either demonstrate its utility and undergo refinement or be discarded altogether.
The challenge many engineers face is the strong inclination to create scalable solutions from the very beginning. We think in terms of design patterns, microservices, and distributed architectures capable of handling millions of users. But such an approach often aligns with the mindset of large corporations, not startups.
In a startup setting, striving for scalability too early can transform into a costly delay, where we optimize for users that don’t yet exist and tackle potential problems that may never arise. My three-month rule encourages the development of straightforward and even “imperfect” code that is deployed quickly, providing invaluable insights into user needs.
Current Infrastructure Strategies and Their Value
1. All-in-One Virtual Machine
My entire infrastructure—database, web server, background jobs, and caching—operates on a single $40/month virtual machine. While this setup lacks redundancy and relies on manual backups, it has yielded significant insights.
In merely two months, I have gained a clearer understanding of my actual resource requirements than any capacity planning document could offer. For instance, my “AI-heavy” platform typically consumes just 4GB of RAM. The intricate Kubernetes architecture I nearly implemented would have required managing empty containers instead.
When issues arise (as they have twice), I gather real data about system failures—typically surprising insights that inform future development.
2. Hardcoded Configuration Settings
Instead of using configuration files or environment variables, I have opted for hardcoded constants like:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
While this practice may seem outdated, it has its advantages. With the ability to quickly search my codebase for any config value, every price alteration is logged in Git history, and my own pull
