How does a small team test an AI product properly before customers see it?

Use the product yourself, daily, on real work with real consequences — not a seeded test account. Build the test set from the inputs that have already broken it, in the messy form they arrived in. Where the output differs every run, assert on what must be true of it, not on what it said. Take one review pass from someone holding the brief and the output but not your reasoning. Then accept the ceiling: dogfooding proves a thing is broken; it never proves anyone wants it, because you are not your customer.

A seeded test account is a tidy world built by the person who also built the software: it holds only the situations that person already thought of. Real work supplies the rest: the record with a typo three systems deep, the note dictated beside a running compressor, the job abandoned halfway and resumed next morning. Those inputs break AI features, and they are hard to imagine in advance.

Keep the stakes real but bounded. Draft-first does that: the software prepares, a person approves, nothing irreversible happens unattended. You can aim it at work that matters and still see failures at full strength, because a wrong output stops at the approval step rather than becoming a wrong outcome. Wilson is the studio's own daily driver rather than a demo; Otto runs against a working two-location repair shop. The test of whether you are dogfooding or performing it: you would be annoyed if someone took the thing away.

Fixtures encode the assumptions of whoever wrote them. That is survivable in ordinary software, where failures cluster somewhere enumerable — nulls, boundaries, off-by-one. AI features fail elsewhere: where language is ambiguous, where a person contradicts themselves mid-sentence, where a trade has its own shorthand, where half the meaning was context nobody said aloud. Nobody writes a fixture like that, because writing test data is an inherently tidy act.

Having a model generate the data makes it worse: a model writes the language a model already handles well. Build the corpus by capture — real inputs, used with permission, stripped of anything personal — and hold one rule: when something fails in live use, that exact input becomes a permanent case, verbatim, noise included. That folder is the most valuable thing the testing effort produces, and it costs only the discipline to keep the ugly ones.

Nondeterministic output is not untestable output. It means asserting on the contract underneath the prose rather than on the prose. For a feature turning a spoken note into a structured repair order: the result parses, every job carries a labour figure, that figure is a number in a plausible range, no part appears that was never mentioned aloud, nothing arrives pre-approved. Those hold across any rephrasing, and invented content fails them at once.

Above that, keep a few dozen real cases graded by hand, each with a note on what a correct answer must contain and must never contain. Run them whenever the prompt, the model or the retrieval changes, and read the diffs rather than the score. Run each case several times: one that passes three runs in five is broken, and an average hides it. Pin the model version, because a provider updating quietly is a regression you did not write. Read twenty full outputs by eye after any significant change, because tone and format drift walk past every assertion you own. Keep the harness to a folder of inputs and a script that prints differences. An evaluation platform built before the product is procrastination with a build step.

Whoever built a feature cannot test it fresh. They walk the paths they designed, read the intended meaning into a vague output because they know what it was meant to say, and perform the missing setup step without noticing their hands did it. The fix is informational rather than organisational: one pass by a reviewer who gets the brief and the output but not the thinking that connects them.

With no QA department that reviewer can be a friend handed only the brief, a second model with an empty context window, or you a day later with your notes closed. Withholding the reasoning is the mechanism — a reviewer who has read your justification will grade your justification. Ask two things: does this do what the brief says, and what is the worst output you can provoke on purpose. Anything touching credentials, money or customer data wants a security review too — a different job from testing.

Dogfooding has a hard ceiling, and ignoring it is how a small team spends six months polishing something nobody adopts. You are not your customer. You can use a repair-order tool all day at a desk and never be a mechanic working a phone through a glove at seven in the morning. Whole categories of truth are invisible from inside: onboarding, because you never onboard yourself; the third day, because your motivation is not theirs; anything where two people hand work to each other; and price. You forgive quirks you know the reason for.

What it does prove is worth having: the thing survives real data, the shape of the workflow is roughly right, and the person who built it will depend on it. The signs it has told you all it can are plain: the bugs have gone cosmetic, you no longer reach for the old way of doing the task, and the arguments left are about preference rather than correctness. Then put it in front of one real user, in their environment, doing their own work, and watch without narrating. An hour of that outranks another month of your own use.

Size it to the blast radius. Two questions settle it: what does the worst plausible output cost, and who stands between that output and the customer. A summary panel beside a database, where a wrong summary costs somebody a shrug, wants ordinary tests and three tolerant early users; an evaluation pipeline will find less and take longer. A feature that writes the document somebody bills from, or that touches money, credentials or customer records, wants the full apparatus.

For a team of one to three in that second category, the floor is a week of setup, not a quarter, and it is mostly discipline rather than tooling: daily use on real work, a growing folder of the inputs that have actually broken it, assertions on structure rather than wording, one review pass uncontaminated by your reasoning, a human approving anything irreversible. Spend what you save on getting the product in front of someone who is not you.

Last updated 25 July 2026.