Embracing the 3-Month Rule: A Pragmatic Approach to Development
In the tech world, the well-known mantra from Paul Graham: “Do things that don’t scale” often gets thrown around. However, what frequently goes unaddressed is how to put this advice into practice, especially when it comes to coding. After eight months of building my AI podcast platform, I’ve arrived at a straightforward yet effective framework: each unscalable approach is given a lifespan of three months. After this period, it either demonstrates its value and is further developed, or it’s retired.
It’s common for engineers to focus on creating scalable solutions from the outset. The allure of design patterns, microservices, and complex architectures designed to accommodate thousands of users can be overwhelming. However, this mindset often aligns more with large corporations than with startups.
In the startup realm, writing scalable code can sometimes become an exercise in unnecessary delay, where you find yourself preemptively optimizing for users who may never materialize or addressing challenges that don’t exist yet. My three-month rule encourages me to produce straightforward, even “imperfect,” code that can be deployed immediately while providing insights about actual user needs.
Current Infrastructure Hacks and Their Strategic Value
1. Single Virtual Machine Deployment
All components—including the database, web server, background jobs, and Redis—are hosted on a single $40/month virtual machine. This setup offers zero redundancy and relies on manual backups.
Why is this advantageous? In just two months, I’ve gained insights into my actual resource needs that would have taken extensive capacity-planning documentation to uncover. It turns out my AI-heavy platform only peaks at 4GB of RAM, making my initial plans for an elaborate Kubernetes configuration unnecessary. When the system crashes (which has happened twice), it reveals real breakdown points—surprisingly, it’s never what I anticipated.
2. Hardcoded Configuration Values
Configurations are implemented as constants scattered throughout the code without separate config files or environmental variables.
For example:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
The benefit? I can quickly search my codebase for any configuration value. Modifying a parameter means simply redeploying—far more efficient than spending a week developing a configuration management system when I’ve only adjusted these values three times in three months.
**3. Using
