Pilot programs and case studies as validation evidence

Somewhere between "we spoke to potential customers" and "we have paying customers" sits a category of evidence that founders consistently underuse: the pilot. A small, bounded trial with a real customer, run to a defined scope and written up properly afterward, does more for a market validation section than most founders realise — and it's achievable well before a business has any meaningful revenue.

The catch is that a pilot only counts as strong evidence if it's documented as one. An informal arrangement that never gets written up, measured, or attributed to a named customer is barely distinguishable from an anecdote, no matter how well it actually went.

What separates a pilot from "we let someone try it"

A pilot is not the same as sending a demo account to a prospect and hoping they poke around. The features that make a pilot count as evidence:

• A named customer or organisation. Anonymous or unnamed "a UK retailer" pilots are much weaker than "Foo Ltd, a 12-person logistics operator in Leeds."
• A defined scope. A start date, an end date (or a review point), and a specific set of tasks or use cases the pilot covers.
• Use of the actual product. Not a mockup, not a manual workaround performed by your team behind the scenes, not a slide deck — the real thing, even in an early or limited form.
• A measurable outcome. Time saved, error rate reduced, revenue generated, cost avoided — something quantifiable that existed before the pilot and changed during it.

A trial that has all four of these is meaningfully different evidence from "a few people have been using our beta." See what counts as a trial customer versus pipeline for how this fits into the broader evidence hierarchy endorsing bodies apply.

Why the write-up matters as much as the pilot itself

Founders routinely run a genuinely good pilot and then fail to capture it properly, which means it can't do any work in the application. Six months later, all that remains is a vague memory: "yeah, that went well, they really liked it." That's not something an assessor can weigh.

A case study captures the pilot while the details are fresh and specific:

1. The customer and their situation — who they are, what problem they had, why it mattered to them.
2. What you delivered — the specific scope of the pilot, what was in and out of scope.
3. The measured outcome — the before/after number, ideally sourced from the customer's own data or confirmed by them.
4. A direct quote from the customer, ideally one that speaks to the outcome rather than generic enthusiasm.

Paid vs unpaid: how much does it matter?

A pilot the customer paid for, even a small amount, sits closer to the paying-customer tier of evidence than the trial-customer tier, because payment is a real financial commitment that an interested-but-uncommitted prospect won't make. An unpaid pilot is still meaningful — it shows genuine usage rather than hypothetical interest — but it's a step down.

If you're negotiating a pilot and have any room to ask for even a token payment (a reduced pilot fee, a deposit, a paid extension after an initial free period), it's worth pursuing purely for the evidential upgrade, separate from the revenue itself.

How many pilots do you need?

One well-documented pilot with a clear before/after outcome is more useful than three vague, undocumented ones. That said, a single pilot invites the question "does this generalise, or was this one customer unusually receptive?" Two or three pilots across different customer profiles (different sizes, different sub-segments) start to build a pattern an assessor can trust, in the same way multiple structured interviews build a pattern that a single conversation can't.

Structuring a pilot so it produces clean evidence from day one

Pilots that produce weak evidence usually weren't designed to produce evidence at all — they were informal arrangements that happened to run for a while. A few structural choices at the outset make the difference:

• Put the scope and success criteria in writing before the pilot starts, even if it's a one-page email rather than a formal contract. "This pilot runs eight weeks, covers reconciling weekly delivery data for two depots, and we'll measure hours spent and error rate before and after" is something you can quote directly in a case study. A pilot that started as "let's just try it and see" rarely produces language this clean afterward.
• Agree a check-in cadence with the customer. A midpoint check-in surfaces problems early and gives you a second, independent data point beyond the final outcome — useful if the end-of-pilot result is ambiguous or the customer is slow to respond to a final review request.
• Ask for permission to reference the engagement before the pilot ends, not after. Customers are generally more willing to agree to being referenced, quoted, or contacted for verification while the relationship is warm and ongoing than after the fact, when the request can feel like an unexpected ask.

Turning a pilot into a permanent customer — and what happens if it doesn't convert

The strongest possible narrative is: pilot, documented outcome, converted to a paying relationship. If that's your situation, present it as a single evidence chain — the case study leading directly into the ongoing paying relationship — rather than as two disconnected facts.

If the pilot didn't convert, don't hide it — address it honestly and briefly, and focus the write-up on what was learned. An assessor who reads a case study that only shows successes, with no acknowledgment of pilots that didn't work out, has reason to wonder what's being left out. A brief, honest note ("two pilots did not convert to paid; feedback indicated timing rather than product fit, and informed our pricing structure") reads as more credible, not less — this is closely related to why demonstrating you're validating a genuine market need rather than a franchise-in-disguise depends on showing you actually engaged with what customers told you, including the negative signals.

What this looks like in the actual application document

A case study section in an application should read as a short, self-contained narrative: customer name (or anonymised with disclosed reason if confidentiality applies), problem, pilot scope and dates, outcome with numbers, and a quote. Attach supporting evidence — an email confirming the pilot outcome, a data export, a signed pilot agreement — as an appendix reference rather than just asserting the numbers in prose.

Sources and further reading

• GOV.UK: Innovator Founder visa guidance
• GOV.UK: Appendix Innovator Founder — Immigration Rules
• Davidson Morris: Innovator Founder visa

Key takeaways

• A pilot only counts as strong evidence when it has a named customer, a defined scope, real product usage, and a measured outcome.
• The write-up matters as much as the pilot itself — capture the baseline and the outcome while details are fresh.
• Paid pilots outweigh unpaid ones, even at a small amount, because payment signals real financial commitment.
• One well-documented pilot beats three vague ones; two or three documented pilots across different customer profiles build a stronger pattern.
• Address pilots that didn't convert honestly rather than omitting them — it reads as more credible, not less.
• Offer pilot customers as verification contacts if they're willing; almost no applicants do this, and it stands out.

• pilot-programs
• case-studies
• market-validation
• evidence
• trial-customers