Corporate innovation leaders ask us some version of the same question on almost every venture-building engagement: “How heavy is your build when you prototype? How much do you build before you get someone willing to pay?”

It’s the right question. Most teams never ask it. They ask a worse one instead: how do we build a product polished enough to prove the idea? So they spend six months and a real engineering budget making something demo-ready, then discover the business model underneath it doesn’t hold. The product worked. The company didn’t.

Here’s the principle we run every build on. Validate the business model before you build the product: build only enough to sign a letter of intent on vaporware, then co-develop the beta with a design partner who has paid to be in the room, because doneness is measured in proven assumptions, not shipped features.

That’s the quotable version. Here’s how it actually works.

Why validate the business model before building the product?

We’re big on business model validation. We want to know that each part of the business model works before we start building product as a whole. Who pays, how much, through what motion, with what cost to serve, and why this team wins. Every one of those is a testable assumption, and none of them requires working software to test.

The reframe that matters: validation tests whether the thing is worth building, not whether you can build it. Almost anything can be built. Those are different experiments, and they call for different artifacts.

In our engagements, corporate teams get this backwards more often than startups do, because corporations are structured to reward visible progress. A working prototype photographs well in a steering committee deck. A validated pricing assumption doesn’t. But only one of them tells you whether you have a company.

What should you actually build during venture validation?

So what do we actually make during venture building validation? A ladder, where each rung is the cheapest artifact that can kill or confirm the next assumption.

1. Words. A crisp articulation of the problem, the customer, and the value proposition. This tests whether the opportunity survives being said plainly. More concepts die here than anywhere else, and that’s the ladder working.
2. Thumbnails and sketches. Rough visual expressions of the solution. These test whether the concept translates: does the customer see what we see, or did something get lost between the problem and the proposed fix?
3. Illustrative front-end designs. Words become thumbnails become sketches, and sketches become designs that look real without being real. These help us validate that we’ve translated the solution properly and that it hits the top value propositions a customer actually wants, not the ones we assumed they wanted. Customers react honestly to something that looks like a product. They speculate politely about a paragraph.
4. The product requirements doc. The designs usually come paired with a PRD that defines the MVP and the roadmap behind it. This is the artifact that turns customer reactions into a buildable spec, and it tests whether the version customers responded to is a version anyone can ship on a startup budget.

Notice what’s absent from the ladder: an engineering team. Every rung is design and language, aimed at the business model, priced in days rather than quarters.

When should you hire the entrepreneur and CTO?

That degree of doneness, validated designs plus a PRD, is usually the point where we hire the entrepreneur, or the entrepreneur and a CTO. Not before.

The reasoning for hiring founders at that threshold is about where learning is cheapest. Past that threshold, we believe a founder team is a more efficient place to go learn and build than a venture-building team. The founders own every subsequent decision, so they should generate the learning those decisions depend on. Hand them a validated business model and a clear spec, and their first hundred days go to building with customers instead of re-litigating whether the customer exists.

What the design partnership actually is

Here’s where “how much do you build before someone pays” gets its concrete answer: less than you think, because the first payment doesn’t buy a product.

We demonstrate what a product could do at a vaporware level, illustrative designs and a sharp value proposition, so that we can get an LOI signed with design partners. The goal of that design partnership is a three-month co-development process to build the beta prototype together. The partner isn’t buying software. They’re buying a seat at the table where the software gets shaped.

And they do pay. Design partners sign on for a nominal cost, but enough that they’re willing to pay and think about it in a meaningful way. Free pilots produce polite feedback and quiet no-shows. A partner with real money committed shows up to the working sessions, fights for their requirements, and tells you the truth when the product misses. Skin in the game is the whole mechanism. Without it, you’re learning at your own expense and calling it traction.

So the sequence is: vaporware earns the LOI, the LOI funds and focuses the co-development sprint, and the beta is born already shaped by a paying customer.

How is AI changing how much you should build?

The vaporware line is not where it was two years ago. AI can take a concept to a functional prototype in days, and the temptation is obvious: why bother with sketches and wireframes when you can ship the real thing in week one?

Our experience: because building more, faster, often makes validation worse.

Each rung of the ladder is thinking, not just an artifact. Wireframes force you to answer the translation question, did we actually understand the problem, before the design gets opinionated. A functional AI-built prototype arrives loaded with a hundred small decisions nobody examined. Customers stop reacting to the value proposition and start reacting to the execution: this button, that workflow, the onboarding screen. The feedback gets noisier at exactly the moment you need it sharpest.

There’s an art to the progression from words to thumbnails to designs. It’s the discipline that keeps the team honest about which assumption each artifact is testing. AI shipping skips that thinking, not just the labor.

So we use AI to compress the rungs, not skip them. A design that took two weeks now takes two days. But the sequence holds, because doneness was never about how fast you can build. It’s about which learnings belong at which stage, and shipping something is not the same as learning something.

How done is done?

So, how done is done? Done enough that someone signs. Not a fan, not a friendly executive sponsor: a design partner with a signature on an LOI and money committed to a co-development sprint.

Doneness is not a measure of how finished the product looks. It’s a measure of how much of the business model you’ve proven, and where the next dollar of learning is best spent. Get that right and the product almost builds itself, because by the time you write production code, you already know someone pays.