Viher IT  /  Services  /  Validation

Proof before the build.

Two weeks that turn “we are building X” into a written list of what has to be true, the cheapest test for each of those things, and a decision rule agreed before the data arrives. Where the fastest test is a working artefact, we build the artefact — a landing page, a clickable prototype, a thin slice that runs.

Generative AI has made building the cheapest thing a founder does. A prototype that needed a technical co-founder and three months now takes a week. That is a genuine gain, and it has an unpleasant side effect: building used to be expensive enough to force the conversation with customers, and it no longer forces anything. The result is teams with a working product, a long roadmap, and a customer list of three people who were being polite.

This engagement puts the expensive question back in front of the cheap one. We write down what has to be true for the business to work — demand, willingness to pay, reachability, the thing you are quietly assuming about how the customer currently solves this — and order them by what would kill the company fastest, not by what is easiest to check. Each assumption gets one test, one signal that counts as a pass, and a decision rule written down before the test runs, so a weak result cannot be reinterpreted as encouraging.

Then we run the tests we can run in the time, and where a test needs something built, we build it. That is the difference between this and a coaching engagement: the person designing the test is the person who can ship the landing page, wire the payment link, or cut a working slice of the product on the same day. Nothing waits for a developer who is not in the room.

The method here is not new. Customer development and the build–measure–learn cycle have been in print since 2011 and 2012 (Ries; Blank & Dorf). What changed is the cost of the build, which is exactly what makes the discipline harder to keep and more worth paying for. It is also the subject Risto is studying formally, in a study whose fieldwork has not happened yet and whose page says so.

The same question, asked where nobody is paying for the answer: the research behind this engagement.

How it runs.

  • Week one: an assumption register, ordered by what would kill the business first, with one test and one decision rule each
  • Week two: the tests that can be run in the time, and whatever has to be built for them to run
  • Decision rules written down before results arrive — the point of the exercise, and the part teams skip
  • Fixed price. You can stop after the assumption register if that is all you needed

What you get.

  • A written assumption register: what has to be true, ordered by how badly it would hurt to be wrong
  • For each assumption, the cheapest available test and the signal that counts as a pass
  • Decision rules agreed in advance, so a weak result cannot be talked back into a good one
  • The artefacts the tests needed — landing page, prototype, thin working slice — built rather than specified
  • A record of what was tested, what came back, and what was decided on the basis of it
  • A business model sketch with the untested boxes visibly marked as untested

A good fit for.

  • Founders with an AI-built prototype and no evidence anyone wants it
  • Teams whose roadmap is long and whose customer list is short
  • Accelerator and incubator cohorts that need evidence rather than another deck
  • Companies running an internal new-business idea with no way to tell whether it is working

Questions we get asked.

Isn't this just Lean Startup with a new name?

The method is Lean Startup and customer development, and we say so rather than rebranding it. The reason it needs buying again is that the economics underneath it changed. When building took three months, the cost of the build enforced the discipline for you. Now that it takes a week, nothing does, and the teams skipping validation are not lazy — they are responding rationally to a build that no longer hurts.

You are a developer. Why are you doing validation work?

Because most validation stalls on something needing to be built. A test that requires a landing page, a payment link, or a working slice of the product gets scheduled, then dropped. Being able to build the test on the day it is designed removes the usual reason validation does not happen, and it keeps the person who wrote the assumption honest about what the result actually showed.

What if the answer is that nobody wants it?

That is a result, and it is the one worth the most. It arrives in two weeks rather than after eighteen months of building, and it usually arrives with a specific reason attached — wrong customer, right customer with a cheaper existing workaround, real need with no budget line to pay from. Two of those three are fixable without abandoning the idea.

Do you use AI in the sprint itself?

Yes, for the mechanical parts: drafting test material, building the artefacts, sorting through what came back. Not for the judgement calls. An assumption register written by a model reads well and is missing the assumption you did not want to look at, which is the one that matters.

How does this connect to the research?

The research asks the same question in a setting where nobody is paying us to like the answer: how founders actually use AI across the innovation process, and whether their work moves into validation or past it. The method feeds the client work now. The findings cannot until they exist — the interviews run in late 2026. See the research page.

Scope note. This is product and business model validation, not market research at survey scale and not investment advice. Small-sample evidence tells you whether to keep going, not what your market is worth. We will say which of the two you are getting.

Next: BuildThe system that runs it.

Cheap to build is not the same as worth building.

Connect
Availability
Fully booked — not taking on new work right now.
The point
Two weeks to find out, instead of eighteen months of building toward an answer nobody asked for.