Stuck-to-Scale asks one question per stage: Define asks whether there is a named buyer and a stated bet specific enough to be wrong. Build asks whether a working version of the thesis exists, even roughly. Validate asks whether anyone outside the founding team has paid, or committed to pay. Repeat asks whether the same buyer type has paid more than once, without a founder in the room. Systemise asks whether the venture runs without the founder personally closing every deal. Scale asks whether adding budget reliably adds revenue, at a known cost.
A team with a working prototype and a handful of friendly design partners often describes itself as validating product-market fit, the Repeat-stage language, when the evidence only supports a Build-stage read.
Why six stages and not a maturity curve
Most venture frameworks describe growth as a smooth curve, more revenue, more users, more team, moving up and to the right. Stuck-to-Scale deliberately does not. It is six discrete gates, each with a specific, falsifiable pass condition, because a smooth curve lets a team round up: a venture at 40% toward "product-market fit" on a continuous scale can describe itself as "getting there," which is true of almost every venture at almost every stage and therefore says nothing. A discrete gate does not allow that softening. Either the same buyer type has paid twice without a founder personally closing the deal, or they have not. There is no partial credit for "we are pretty confident it would happen."
That discreteness is the entire mechanism. A framework built to be diagnostic, not just descriptive, has to produce an answer a team can be wrong about, and a continuous maturity score, precisely because it always has some defensible partial value, almost never produces an answer specific enough to be wrong. Six gates, six binary-ish questions, six chances for the evidence to say no clearly enough that nobody in the room can talk their way around it.
What each gate is actually testing
Define is not testing whether a team has an idea, every team has an idea. It is testing whether the idea has been narrowed to a bet specific enough that a specific outcome would prove it wrong. "We help businesses with AI" fails Define regardless of how much conviction sits behind it, because there is no outcome that could disprove something that vague. "We help mid-market logistics companies cut manual dispatch time using an agent that reads incoming orders" passes Define, whether or not it turns out to be true, because it names a buyer, a mechanism and a claim specific enough to fail.
Build is not testing whether the product is polished, it is testing whether the thesis from Define has been made real enough to put in front of the buyer it names, even roughly, even manually behind the scenes if the automation is not built yet. A working prototype with placeholder logic and a founder manually completing steps a real system would eventually automate still passes Build, because the test is "does the thesis exist in a form someone can react to," not "is the engineering finished."
Validate is the first gate that requires a stranger. Not a friend of the founder, not a warm intro who agreed to try it as a favour, someone outside the founding team’s existing relationships choosing to pay, or making a real commitment to pay, on the strength of the thing itself. This is the gate most teams round up on, because a handful of friendly design partners feels like external validation and is not quite the same claim. A friend saying yes tests whether the founder is likeable. A stranger saying yes tests whether the thesis is real.
The gates that get skipped in the retelling
Repeat and Systemise are the two stages most often collapsed into each other in a pitch, and they are testing genuinely different things. Repeat asks whether the same buyer type, not the same specific buyer, the same type of buyer, has paid more than once, without a founder personally in the room closing the deal. This is the gate that separates "we found one motivated segment" from "the segment itself is repeatable," and it is where a lot of ventures that look strong on Validate quietly stall, because the first several sales were driven by founder charisma and relationship capital that does not scale to buyer number twenty.
Systemise asks a related but distinct question: does the venture run without the founder personally closing every deal. A venture can pass Repeat, the same buyer type keeps saying yes, while still failing Systemise, if every one of those yeses still required the founder personally on the call. That is a real, common, and specifically diagnosable failure mode: repeatable demand with a distribution bottleneck that is one person deep. The fix for a Repeat failure and the fix for a Systemise failure are different projects, and conflating the two gates into one vague "are we getting traction" question hides which project actually needs doing.
Scale, the final gate, is not asking whether the venture is growing, it is asking whether growth is purchasable at a known cost. Can the team add a specific amount of budget and reliably get a specific amount more revenue back, at a ratio that holds as the budget increases. A venture growing entirely through founder hustle and organic word of mouth has not answered this question yet, no matter how good its growth rate looks on a chart, because nobody has tested whether that growth is a function of spend or a function of the founder’s specific, non-repeatable effort.
The most common misdiagnosis is a team reading its stage from ambition rather than evidence. The framework’s value is forcing the answer to come from what actually happened, not from momentum or how the round is being pitched.
Running the exercise without letting the room lie to itself
To run it, have every founder and lead answer the six questions independently before discussing as a group. The disagreement inside the room, usually, is the most useful output of the exercise, more useful than the stage label itself.
The independence matters more than it sounds like it should. Ask the six questions as an open discussion and the most senior or most confident voice in the room anchors everyone else’s answer before anyone has had to commit to their own read, a founder who genuinely believes the venture has cleared Validate will, without meaning to, walk the room toward agreeing before anyone with a quieter, more skeptical read has said a word. Written, independent answers, collected before discussion starts, preserve the disagreement long enough for it to actually surface. That disagreement, one co-founder confidently marking Repeat, another quietly still at Validate, is frequently the single most useful piece of information the exercise produces, because it means the team has not actually agreed on the evidence, only on the story.
What tends to happen once the independent answers are compared is not a clean resolution in one direction. It is a specific, arguable conversation about which piece of evidence counts, did that second sale really happen without the founder in the room, or did the founder join "just to answer questions" in a way that quietly did the closing work. That level of specificity is the point. A vague disagreement about "are we doing well" cannot be resolved with evidence. A specific disagreement about whether one named account counts as evidence for Repeat can be, in the same sitting, by pulling up the actual call notes.
What to do with the answer once you have it
A venture that runs this exercise honestly and lands on, say, Build when the pitch deck has been describing Repeat-stage language for two consecutive quarters is not receiving bad news, whatever it feels like in the room in the moment. It is receiving the single most useful piece of information available to it: the specific, falsifiable next gate to clear, instead of a vague sense that things should be going better than they currently feel. Naming the stage honestly before a diligence process or a skeptical buyer names it for you is strictly cheaper every time, and it is the entire reason this framework exists as a self-administered check rather than only an outside audit.
The gap between the stage a team believes it is in and the stage the evidence actually supports is not usually a sign of dishonesty. It is a sign that ambition and evidence produce different answers by default, and nothing forces them back into alignment except a deliberate, specific, occasionally uncomfortable exercise like this one, run often enough that the gap never gets a chance to compound into a story the whole company has started believing.
A note on the stage names themselves
The six stage names are load-bearing across everything else this framework touches, the same six words appear in how a team describes its own status, in how a diligence process phrases its findings, and in how this studio scopes an engagement once a stage has been named. That consistency is deliberate: a shared, stable vocabulary for stage is what lets a founder, an investor and an outside diagnostician have the same conversation using the same six words, rather than three different maturity models talking past each other. Changing the names casually would break that shared reference for everyone already using it, which is a real cost worth weighing against whatever marginal clarity a renaming might offer.
How often to actually run it
A single Stuck-to-Scale read is useful. A cadence of them is where the framework earns its keep, because the gap between story and evidence does not open all at once, it accumulates a few weeks at a time, each individually small enough to explain away, until a team looks up and finds itself two full gates ahead of where its actual evidence supports. Running the exercise on a fixed schedule, independent of whether anything eventful has happened recently, catches that accumulation while it is still a small correction rather than a painful one.
The right cadence is shorter at earlier stages, where the underlying facts change fastest, and can stretch out once a venture has cleared Repeat and the pace of genuinely new evidence slows. A Define-stage team second-guessing its own bet weekly is being appropriately paranoid; a Scale-stage venture with years of consistent unit economics does not need the same frequency, because the six questions are not likely to have moved much since the last time they were asked.
The framework’s actual limit
Stuck-to-Scale is deliberately silent on one thing worth naming directly: it does not tell a team whether the underlying bet is a good one, only what stage of evidence currently exists for it. A venture can honestly clear every gate up through Repeat on a thesis that is nonetheless too small a market to be worth the founding team’s time, and the framework will not flag that on its own, it will simply confirm that the small thesis has been validated, correctly, on its own terms. Stage honesty and thesis quality are two separate judgements, and conflating them is its own kind of misdiagnosis.
That is by design, not an oversight. A framework that tried to score thesis quality and stage evidence in the same pass would blur two questions that need different kinds of judgement to answer well, one is close to a factual check (did this specific thing happen, yes or no), the other is a genuinely uncertain bet about market size, timing and competitive dynamics that no six-question checklist should pretend to resolve cleanly. Stuck-to-Scale is built to answer the factual half reliably, precisely so the harder, more judgement-dependent half does not get skipped by accident while a team is busy congratulating itself on a stage label.
Used this way, a recurring, honest, independently-answered check on the factual half, paired with a separate and ongoing conversation about whether the underlying bet is still the right one, the framework does what it is actually built to do: keep a team’s stated stage and its true evidence close enough together that the gap between them never has room to become the story the company tells itself instead of the one the evidence actually supports, in the pitch deck or in the room.
