To show AI benchmarks on your website, publish how you test, not just the score. Give the method its own page: what the test set is, who checked the answers, the result for each task, the cases where your product gets it wrong, and the date of the last run. A single accuracy percentage in the hero is the weakest version of this, because every competitor has one and nobody can check it.
This matters most to the founder who keeps getting called a wrapper. The work that took eighteen months, the eval suite and everything it caught, has no screen. Your website is the only place a buyer, an investor or a candidate will ever see it, so the method has to be legible there, to someone who has never opened your dashboard.
The badge that says ninety-nine percent accurate
Picture an AI tool that reads commercial insurance policies for brokers. This is an example, not a client. A broker uploads a policy PDF and gets back a checked summary: limits, deductibles, the named insured, the policy period, the exclusions and every endorsement that changes them.
The homepage hero says Read every policy in under a minute. Under it sits a strip of three badges. A green one reads ninety-nine percent accurate. The next says Trusted by brokerages in 30 states. The last says Built on leading models. The button says Book a demo.
Now picture what the team actually has. An eval set of 2,400 real policies from 31 carriers, shared with permission and stripped of client names. Two licensed brokers checked every one by hand. The suite scores 18 fields per policy, one by one, and it runs before every release. The team knows exactly where the tool is strong and where it slips. On the policy number and the named insured it almost never misses. On exclusions that a policy pulls in by form number only, with the wording printed somewhere else, it gets 212 of 260 right, and it flags the rest for a person to read.
None of that is on the website. The ninety-nine is an average across all 18 fields, so the easy fields carry the hard ones. And the badge that says Built on leading models tells a stranger the one thing the founder least wants them to believe.
What happens on the call after the badge
In this example, the head of operations at a mid-sized brokerage books a demo. Ten minutes in, she asks the question the badge invites: ninety-nine percent of what? The founder shares his screen and opens the eval dashboard. The columns are named things like f1_exact and excl_ref_v3. She asks for something she can forward to her compliance lead. He promises a write-up, spends a Sunday on a six-page document, and she never opens the attachment.
The same week, someone replies to his launch post with one word: wrapper. He drafts an answer about the eval set, reads it back and deletes it. An investor asks what happens when the model provider ships document reading of its own. He gives the long answer, badly, because the short answer is not written down anywhere he can point to.
The cost is not lost traffic. It is a slower sale and a weaker raise. Seed-stage AI startups raise at valuations roughly 42 percent above non-AI peers, and that premium assumes you are more than a thin layer. The Series A bar for AI startups is around 3.5 million in ARR (Carta, Q1 2026), up from roughly one million three years earlier. A company that cannot show its depth has to clear that bar while also arguing it would survive a better base model. As we cover in what investors look at on your website, investors open the site again after the meeting. The second visit is when your eval page either backs up the pitch or does not exist.
Why one accuracy number does more harm than good
Most advice says lead with your best number. Put it in the hero, make it big, repeat it in the deck. For AI products we think that advice is wrong, and here is why.
A bare percentage cannot be checked, so a careful reader treats it as marketing. Everyone in the field knows benchmarks get gamed, so a number with no method reads as the vendor's best day. Every rival shows a number in the high nineties, so yours sits beside theirs with nothing to tell them apart. And it hides your best work. The hard part of this tool is not reading a policy number. It is knowing when it is unsure and saying so. A blended average makes that skill invisible.
The stronger move is the one founders resist: publish where the product fails. A team that can describe its own failure cases in exact detail has obviously tested it. A wrapper cannot write that page, because a wrapper has never looked. Showing the work on the answer screen is covered in how not to look like a ChatGPT wrapper. This post is about the page that explains how the work is checked.
The How we measure accuracy page, block by block
Give it its own URL and link to it from the badge, the footer and the pricing page. Keep it to one scroll on a laptop. Here is the order that works for the insurance tool, and it carries over to most AI products.
First, one plain sentence about the test. We test every release on 2,400 commercial policies from 31 carriers, checked by hand by two licensed brokers. Second, what is in the set and what is not. Which lines of business, how many scanned versus digital PDFs, and the fact that no customer document goes into it without consent.
Third, a table with one row per field. Field name, how many we tested, how many we got right, what happens when it is unsure. Written as counts, not percentages: Deductible, 2,371 of 2,400. Exclusions by form number, 212 of 260, the other 48 flagged for review. Counts tell the reader how big the test is. A percentage hides it.
Fourth, a dated line at the bottom: Last run 14 October, after moving to a new model version. Results from the previous run, linked. That line does more for trust than any badge, because it proves someone is still looking.
Three failure cases, written out in full
This is the block nobody publishes and the one buyers read twice. For each failure case, show a cropped, redacted snippet of the kind of document that trips the tool, what the tool returned, and what it does now. For the insurance tool, three are enough.
- An endorsement printed on a separate scanned page that lowers a limit set earlier in the policy. The tool used to report the original limit. It now reads endorsements last and shows both numbers, with the change marked.
- A schedule that lists the per claim limit and the aggregate limit in one table cell. The tool sometimes swaps them. It now flags any cell holding two amounts for a person to confirm.
- Exclusions named by form number with no wording in the PDF. The tool cannot read what is not there, so it lists the form number and says plainly that the text was not included.
Notice what each case proves. The team found the problem, can name it exactly, and changed the product. That is the opposite of a model call with a logo on it.
Comparing against named models without starting a fight
Buyers will compare you to a general chat assistant whether you show it or not, so it is better to run that test yourself. Run the general model on the same eval set, with the same documents, and publish the result next to yours. Say which model, which version, the date you ran it, and the exact prompt you used. Show the fields where the general model does as well as you. Leaving those out makes the rest look picked.
If naming a rival feels risky, label the other systems Model A, Model B and Model C and describe the method in full. the site we designed and built for Chariot does this. Its benchmark panel shows blind pairwise human ratings across four systems, with the number of raters, samples and prompt categories printed beside the chart, and the other systems unnamed. A research lab can show its results and its method at once, without a single adjective.
If you sell to engineers, the rule is stricter: every chart needs its method in one line under it. Our post on AI infrastructure websites goes deeper on that reader. And never quote a public leaderboard score you did not run yourself, as if it were your own test.
When the model underneath you changes
Your provider will ship a new model version, and sometimes retire the old one with little notice. Every migration is a reason to rerun the suite and update the page. Keep the old results one click away. A page that shows two runs, before and after a model change, tells a buyer that a provider update will not quietly break their work, which is the real question behind the wrapper jibe.
Some things should never go on the page. No customer names, logos or documents from the test set. No client metrics. No claims about a rival's failures that you did not test and date. No internal metric names a buyer has to decode. And if you sell into a regulated field, have counsel read any claim with words like compliant or certified before it goes live.
Publish your eval page this week
You need your engineer for two hours and one afternoon of writing. Do it in this order.
- Ask your engineer for the latest eval run, broken down by task or field, as counts. If the suite only reports one blended number, that is the first thing to fix.
- Write the one-sentence test description. What, how many, checked by whom. If you cannot write it plainly, a buyer cannot read it.
- Pick your three worst tasks and write a failure case for each: the input that trips it, what it returned, what it does now.
- Run a general chat assistant on a slice of the same set. Record the model, version, date and prompt. Publish the fields where it matches you too.
- Replace the hero badge with a link: See how we test. Put the same link in the footer and next to pricing.
- Add a Last run date and a calendar reminder to update it on every model change.
- Send the page to one buyer who passed on you, and ask whether it answers what they wanted to know.
Studio Maydit designs websites for AI founders in the US, UK and Europe, and the hard part of the job is usually this one: making the depth you built legible to a stranger in one scroll. We work to a fixed scope of three to four weeks or on a monthly retainer, and you can see what that covers on our page about website design for AI companies. If your site says ninety-nine percent and nothing else, book a 30-minute call.





