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
