Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Tech Solutions
In the world of startups, one piece of advice stands out: “Do things that don’t scale.” This wisdom, often attributed to Paul Graham, carries essential insights for entrepreneurs. However, the challenge lies in translating this philosophy into actionable technical strategies, particularly in the realm of coding.
After dedicating eight months to constructing my AI podcast platform, I’ve formulated a straightforward yet effective framework: each non-scalable hack is allotted a lifespan of three months. During this period, it either demonstrates its value and evolves into a robust solution, or it is discarded.
As engineers, we are often conditioned to prioritize scalability from the outset. We think in terms of design patterns, microservices, and elaborate architectures that accommodate millions of users. But this mindset can be counterproductive in a startup environment. Focusing too much on scalable solutions can lead to costly delays, as we may end up preparing for challenges we haven’t yet encountered. My 3-month rule encourages the development of simpler, more direct code that facilitates timely shipping and reveals genuine user needs.
Current Infrastructure Hacks and Their Strategic Benefits
1. Unified Virtual Machine (VM) Setup
My entire application stack—including the database, web server, background jobs, and Redis—resides on a single $40/month VM, with no redundancy and manual backups stored locally.
This seemingly imprudent choice has proven to be insightful. Within two months, I’ve gained a clearer understanding of my resource requirements than any extensive capacity planning document could provide. Surprisingly, my application’s peak resource demand is just 4GB of RAM. The overly complex Kubernetes setup I nearly implemented would have resulted in managing empty containers, wasting precious time and resources. Each time the system crashes—twice already—I’m provided with practical data about what genuinely fails, which is often unexpected.
2. Hardcoded Configuration
With vital constants like pricing tiers and user limits directly embedded in the code, adjusting configurations means redeploying the application.
While it may seem counterintuitive, this method simplifies my workflow. I can quickly search for any configuration value throughout my codebase. Moreover, any changes I make are meticulously tracked through version control, and every configuration update, albeit minor, goes through a personal review process. Construction of a separate configuration service would require considerable time—approximately a week—but in the past three months, I’ve made only three changes. The quick redeployment
One Comment
Thank you for sharing this pragmatic approach to balancing rapid experimentation with technical decisions that often feel counterintuitive. The “3-Month Rule” is a compelling framework, especially in the startup context where time-to-market and learning are critical. I appreciate how you emphasized that initial simplicity—like using a single VM or hardcoded configs—can provide invaluable real-world insights that drive better long-term decisions.
This approach resonates with the idea that chasing perfect, scalable architectures too early can delay validation and learning. Sometimes, “doing things that don’t scale” upfront yields the most clarity, enabling you to prioritize features or improvements that genuinely meet user needs. The key, as you pointed out, is to set a clear lifespan for these hacks—three months—and be disciplined in evaluating whether they evolve or are phased out.
Have you considered a structured review process at the end of each cycle to decide on next steps? This might help ensure that valuable insights don’t get lost, and it can smooth the transition from quick hacks to more scalable solutions when the time is right. Overall, your framework is a valuable addition to the startup toolkit—balancing agility with strategic reflection.