Embracing the 3-Month Experimentation Rule in Software Development
In the realm of startup culture, there’s an age-old adage by Paul Graham that often circles around: “Do things that don’t scale.” While this advice is well-known, the challenge lies in how to effectively apply it, particularly in the tech world.
After eight months of developing my AI podcast platform, I’ve established a fundamental approach: each experimental, non-scalable hack gets a lifespan of just three months. This timeframe serves as a litmus test—after three months, if the hack has demonstrated its value, it deserves a proper build. If not, it’s time to let it go.
Engineers are typically trained to pursue scalable solutions from the outset. They delve into design patterns, microservices, and distributed systems, crafting sophisticated architectures capable of accommodating millions of users. However, such thinking can lead to premature optimization in a startup environment. When developing for a user base that doesn’t yet exist, you might find yourself solving problems that aren’t even on the horizon.
My 3-month rule compels me to focus on crafting straightforward, albeit “bad,” code that gets delivered. This method allows me to gain genuine insights into user needs while avoiding the trap of building for future projections that may never materialize.
Current Infrastructure Hacks: Why They’re Working
1. Consolidation on a Single Virtual Machine (VM)
Currently, my setup involves running everything—a database, web server, background jobs, and Redis—on a single $40/month VM. While this lacks redundancy and requires manual backups to my local machine, it has proven incredibly educational. In just two months, I’ve gained a clearer understanding of my resource needs than any formal capacity planning report could provide. For instance, my application primarily operates within a 4GB RAM limit. The elaborate Kubernetes arrangement I nearly implemented would have only served to manage idle containers.
When the system crashes (which has happened twice), I gather real-time data about the causes. Interestingly, they’re rarely what I initially expected.
2. Hardcoded Configuration Values
I’ve opted for hardcoded constants—such as pricing tiers and user limits—scattered throughout my codebase. Although this might seem inefficient, it has its advantages. I can quickly search through my entire code for any configuration value. Any changes I make are easily tracked via Git history, and every modification undergoes code review—even if conducted by just myself.
Constructing a dedicated
One Comment
This post beautifully highlights the importance of embracing rapid experimentation and avoiding premature optimization—especially in early-stage startups. The 3-month rule acts as a pragmatic safeguard, encouraging founders and engineers to validate ideas through real-world feedback rather than over-engineering solutions upfront.
Your approach to infrastructure—consolidating everything on a single VM and using hardcoded values—may seem “bad” from a classic scalability perspective, but it’s an excellent reminder that simplicity and agility often beat complexity in the initial phases. This method allows for faster iteration, deeper understanding of user needs, and better data-driven decisions on where to invest later.
I’d add that this mindset aligns with the broader lean startup philosophy: build, measure, learn. By setting clear time boundaries for experiment evaluation, you create a disciplined rhythm that ensures resources are used efficiently, and ideas are validated without unnecessary delays or overbuilding. As the product evolves, these small hacks can be integrated into more scalable systems, but the key is knowing when to pivot or scale based on concrete insights, not assumptions.
Thanks for sharing such a thoughtful framework—I believe it can serve as a valuable blueprint for many founders championing smart, purpose-driven development.