The rule
  • Nothing should run more than three months of build without meeting a real user. Not a demo to the board, not a walkthrough for the investor. A real user, doing the real thing.
  • Milestones fail when they are calendar-based instead of evidence-based. A date measures whether you shipped. It says nothing about whether it worked.
  • Define what evidence means before you start the clock: your riskiest assumption, and the result that would count as validated. The Leap does this in the browser.
  • Three months is not arbitrary. It is roughly the size of bet a startup can afford to get wrong, and roughly the runway you should be able to name to the month.

A team I met had been building for eight months and had not once put the thing in front of a real user. Not out of laziness. The opposite. They were disciplined, they hit every milestone, the burndown charts were beautiful. There were demos, but the demos were internal, and the feedback was from people who already believed. Then, at month eight, they finally sat a real customer in front of it, and inside ten minutes it was clear they had spent eight months and most of a seed round building the wrong half of the product. Everyone in that room was good at their job. The process was the problem, and the process had a specific flaw: every milestone was a date, and not one of them was a user.

So the rule is blunt on purpose. Nothing runs more than three months of build without meeting a real user. Not a stakeholder, not a friendly beta of people who love you, not a click-through for the investor. Someone who has the problem, using the actual thing, with you watching. If you cannot get to that inside three months, you have not scoped a milestone, you have scoped a leap of faith, and you are about to take it with your eyes closed.

Why calendar milestones lie.

Most roadmaps are built out of dates. Ship onboarding by the end of Q2. Payments live by August. Beta in the autumn. These feel like milestones because they have a deadline attached, but a deadline only measures one thing: whether you shipped. It is entirely possible to hit every date on that list and still be building something nobody wants, because none of those milestones contains a claim about the outside world. They measure your effort, not the market's response, and effort is the one thing a committed team can always produce.

An evidence-based milestone looks different. It is not "ship onboarding by Q2", it is "by Q2, ten target users complete onboarding without help". Same feature, same deadline, but now the milestone has a fact in it that the world has to supply, and the world can refuse. If nine of the ten get stuck, you have not missed a date, you have learned something that no amount of internal demoing would have told you. That is the whole difference. A calendar milestone can only be met or missed. An evidence milestone can be met, missed, or, most valuable of all, proven wrong.

A deadline measures whether you shipped. A gate measures whether it worked.

Define the evidence before you start the clock.

The rule is easy to say and easy to fudge, because "meet a real user" can become a box-ticking demo if you have not decided, in advance, what you are trying to learn. So the real work happens before the three months begins, not at the end. Before you write a line of code for the next cycle, name the one assumption the whole build rests on, and decide the result that would count as validated. That is your gate. Then build toward the cheapest version that could test it, not the most complete version you can imagine.

This is exactly what The Leap is for. It maps the assumptions your plan is standing on, scores them on impact and evidence, and surfaces the one that matters most and rests on the least proof. That is the assumption your three months should be aimed at, and the tool points you at the cheapest experiment to test it. Write the pass mark down while you are still calm and objective: not "users will like it", but "at least half of the ten we sit down finish the core task and come back the next day unprompted". Decide the exam before you sit it, because once you are attached to what you built, you will grade yourself generously.

Diagram · the three-month build cycle
The three-month build cycle with a milestone gate A loop of three stages. First, define the evidence: your riskiest assumption and the pass mark. Then build for up to three months. Then the gate: meet a real user and check the result against the pass mark. From the gate, the loop returns to define the next evidence, deciding whether to continue, pivot or stop. No more than three months of build passes between one real user and the next. continue, pivot or stop Define the evidence the riskiest assumption + the pass mark Build the cheapest test, up to three months THE GATE Meet a real user check the result against the pass mark
Three months is the longest the loop is allowed to get. The gate is a real user, checked against a mark you set in advance, not a demo to people who already agree.

Run the loop and the whole rhythm of the company changes. You stop asking "are we on schedule?" and start asking "what did the last user tell us, and what does this next block of work need to prove?". The build gets shorter and sharper, because a three-month ceiling forces you to cut the version down to the part that actually tests the bet. And the demos to believers quietly stop mattering, because the only audience that counts is the one that can say no.

Three months you can actually name.

There is a second reason the number is three, and it is about money, not just learning. Three months is roughly the largest bet an early startup can afford to get wrong. Build for a year against a wrong assumption and you have spent the company. Build for three months and you have spent a correction you can absorb. The rule is really a cap on how much you are willing to lose before the market gets a vote.

Which is why it ties straight to your runway. Most founders quote a runway they hope they have rather than one they can name to the month. Work out the real number, cash over net burn, and the day it hits zero, and the three-month rule stops being a productivity tip and becomes a survival one: never let a build cycle run longer than the mistake your runway can absorb. The free Runway Calculator gives you three months you can actually name, instead of three months you are quietly hoping for. Pair the two, evidence before the clock and a runway you can count, and you have the whole discipline in one sentence: do not spend money you cannot name on a bet you have not checked.