Does your AI product actually work?
Unblo answers that before you ship.
We build test users out of research you already have, then open a real browser for each one and let them work through your live product the way a person would.
What comes back is a readout: what happened to the people who used it, where they stopped, and whether you can ship.
We're currently onboarding our first clients. Talk to us to get access to the product.
Can the assistant actually cancel a subscription, or does it just say it did?
All three were told it was cancelled. On all three, the billing page still showed the plan active. Two users never checked and closed the chat believing they were done.
Nobody is answering the question you actually have.
You can tell whether a model returned something reasonable. You still cannot tell whether a person got what they came for.
Built for engineers debugging a system.
Traces, spans, JSON. They score model outputs and they're good at it. They can't tell you a user gave up on step four, because they never watched anyone try.
Tools like Langfuse, LangSmith, Arize Phoenix
Asks the right question, at the wrong speed.
You get real answers about real people, six weeks later, after paying to recruit them. So nobody runs it on a release, and quality ends up judged on vibes.
Requires: recruiting, scheduling, moderating, synthesis
The usability question, per release.
Test users grounded line by line in research you already own, working through your live product in a real browser. You get a lot of what you'd learn from research, in a much shorter time.
Made to be read by a PM, a designer, a founder
From your research to a readout, in four steps.
Point us at what you already know
Interview recordings, support transcripts, product docs, your marketing site. We parse them and keep the line references.
PostHog session recordings can also be used to ground your test users in how people move through a page. Coming soon.
We use this data to build grounded test users
Each one carries seven observable behaviours. Every behaviour names the line it came from, or says outright that it was inferred.
Test users, not test cases.
They use your live product
One real browser session per test user, on the product you actually shipped. Behind your login, scoped to the domains you name.
A gaze model we trained blurs what a person wouldn't have looked at, so each user acts on what they would have seen instead of the whole page.
You see what didn't work in the readout
What happened, where they stopped, and the screen where it happened. The worst problem goes first: the one that hit the most test users and did the most damage to their run. Nothing gets summed into a number.
You forward it to your team. There's nothing to log into.
Seven behaviours you could watch someone do.
A persona is a paragraph about someone who doesn't exist. A test user is seven fixed fields describing what a person scans, clicks, waits for, compares, says and abandons. For grounded users, each field can be traced back to your research.
Behaviours, not adjectives.
"Impatient" isn't a trait. You can't watch someone be impatient. "Waits briefly for progress, retries once, then abandons an unclear flow" is a trait, because it produces a session you can sit and watch.
The schema is closed.
All seven fields are required on every test user. Nothing extra gets accepted, nothing is left blank, and a user missing a field doesn't get built. That's what makes two runs comparable.
Provenance or nothing.
Each behaviour cites where it came from: the interview and timestamp, the ticket, the document. Where we had to fill a gap, the field says so outright instead of quietly passing itself off as evidence.
The readout is the product.
It gets forwarded into a channel and it settles an argument. So it's built to be read straight through by someone who has never opened an eval tool. Here's every part of one, in order.
A title that's a question
A run is an attempt to answer something specific. The title says what.
Can the assistant actually cancel a subscription, or does it just say it did?
The answer, in two sentences
Read nothing else and you still have the finding, and enough to decide whether to ship.
All three test users were told their subscription was cancelled. On all three, the billing page still showed the plan active a minute later. Two of them never checked, and closed the chat believing they were done.
Where people stopped
How many people got through each step. No average and no letter grade.
The decisive moment of each session, at full size
The frame where it turned, big enough to actually look at, with what the test user was doing underneath.
The sharp region is where the gaze model predicts a person would have been looking. Everything the eye would have skipped stays blurred, both in the readout and for the agent deciding what to do next.
What went wrong, worst problem first
Ordered by how many test users ran into each problem and how badly it derailed them: misled, stuck in a loop, or told something false.
The assistant confirms a cancellation the rest of the product never shows
All three were told the plan was cancelled in plain language. On all three, the billing page still read "Pro · renews 14 Aug" a minute later. Two users left without ever seeing that screen.
The chat and the billing page disagree, and nothing reconciles them
Two screens, two answers, no third place to check. One user reopened the chat three times trying to work out which one to believe, and got the same confirmation each time.
It answers policy questions it should hand off
Asked whether cancelling mid-cycle means a refund, it stated a pro-rata rule that doesn't appear anywhere in the policy document you gave us.
What already works, and shouldn't break
The parts that went fine, written down, so that fixing something else doesn't quietly break them on the next run.
- All three got the assistant to understand the request on the first message. Nobody had to rephrase.
- It pulled the right account and the right plan every time, including the user with two subscriptions.
- When one test user switched to French mid-conversation, it switched too and kept the thread.
And then it stops
The readout ends here, on purpose.
There's no "recommended next steps" section. We can tell you what happened, because it happened and we watched it. What you should do about it would have to be invented, and you know your product far better than three sessions do.
What you do with it is hand it over: to your coding agent, your product team, your developers. Then run the same setup again and see whether the problems it found are actually gone.
Four rules we build against.
We don't give you a score
No number at the top of the readout, no grade on this page. Average three separate problems together and you get something like "72, fine," which is how a broken cancellation flow ends up looking acceptable. A number also gives you a reason to stop reading.
So you get the sentence instead. All three were told it worked, and billing still said otherwise, plus the two screens where it happened.
Every claim names its source.
Traits, quotes, findings: each one points at the interview and timestamp, the ticket or the document it came from. Where nothing supported it, the claim is marked inferred rather than dressed up as evidence.
Every finding is anchored to a frame from the session: the screen, the timestamp, the test user who was there. You don't take our word for it. You watch the moment.
It runs against your real product
Not a mockup, not a staging clone, not a description of your product we assembled from your docs. A real browser session against the URL you give us, behind your login, scoped to the domains you name.
Which means you don't have to take our word for any of it. The sessions show up in your own logs and analytics, with the timestamps to match.
You can run it again after you ship the fix
Same test users, same task, same steps, so the two runs are actually comparable. The new one lands next to the old one rather than somewhere you have to go digging for it.
Then you watch that last step go from 0 of 3 to 3 of 3. That's what tells you the fix landed for the people it was meant for.
We built this because we needed it ourselves.
We met in high school in Poland eleven years ago and spent the last three years shipping AI products side by side at Stonly. Łukasz built the eval harness. Antoni turned what it said into something the whole team could act on. Both jobs were worth doing properly, and both competed for time with shipping the product, which is a trade every team we've met is still making.
Since then we've spent most of our time talking to teams shipping agents. Almost all of them test the same way: someone clicks through it before a release and hopes. The only team we found that had solved it, and was happy with what they'd built, had put together a user simulation system in-house. They now spend more on it in compute than a standard salary, because what it tells them is worth that much.
We're based in Paris. Unblo, Inc. is a Delaware C Corp.
Bring us a product and a question.
Thirty minutes. Tell us what you're shipping and what you're unsure about, and we'll set up the first run against it with you. Nothing to install beforehand.