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
One Comment
Thank you for sharing this practical and refreshingly honest approach to balancing experimentation with progress. The 3-month rule aligns well with the concept of getting quick feedback loops—focusing on delivering value early and learning what works before overengineering. I especially appreciate the emphasis on starting with simple, unscalable solutions, such as deploying on a single VM and hardcoded configs; these choices can dramatically reduce friction during early development phases, enabling faster iterations.
It’s interesting to note how these “imperfect” solutions often reveal real bottlenecks or resource needs faster than sophisticated planning. The key, as you pointed out, is to set a fixed horizon—three months—after which you assess if the approach warrants further investment or if it’s time to pivot.
This mindset is particularly valuable for startups and solo developers who need to move quickly without getting bogged down in premature optimization. Have you considered documenting the decision points around when to evolve these solutions, or do you prefer a more organic evolution based on the insights gathered during each cycle? Overall, this framework offers a compelling blueprint for practical innovation.