The Bug Only a Robot Could See

In August of 2026 a customer tried to buy our migration product. The checkout asks for your email address twice before it takes your money — a small courtesy we added after learning the hard way that a mistyped email means a license key sails off into the void.

The customer clicked the buy button. The email form appeared. They started typing.

Nothing showed up.

The field looked broken — blank, dead, ignoring every keystroke. They tried again. Still blank. They assumed the field wanted a password and was hiding the characters, except no dots appeared either. So they did what most customers do at that moment, the moment every SaaS founder should lose sleep over: they stopped.

Here's the thing. The field wasn't broken. It worked perfectly.

The text was white. The box was white.

They had typed their email correctly — twice, in fact, on a later attempt, because our little "emails match" indicator lit up green beneath two apparently empty boxes. Everything functioned. Nothing was visible.

Why every human missed it

That checkout had been tested. Repeatedly. By us, by real users, by the person who built it. Every test "passed."

It passed because human testers carry an unfair advantage that makes them terrible witnesses: they know what they typed. When you type your own email into a form, you don't verify it by reading the screen — you verify it by trusting your fingers. Your eyes slide to the next button while the field is still rendering. A tester who typed test@test.com sees the green checkmark, clicks Continue, reaches Stripe, and marks the flow as working. The screen never actually showed them anything, and they never noticed, because they weren't looking.

This is not a rare failure. It's a whole category. The technical cause was mundane — the form sat on a dark-themed page, inherited the page's white text, and nobody had pinned the field's own color. One missing line of styling. The kind of bug that produces zero errors, zero crash reports, zero failed tests. Functionally perfect. Visually invisible.

Your error monitoring will never catch it. Your unit tests will never catch it. Your uptime dashboard will report a proud row of green checkmarks while customer after customer types into the void and quietly leaves.

What caught it

A camera.

We build VideoCrunch, a tool that produces software tutorials by driving a real browser through a real product while an AI narrates. No screen-recording a human presenter — a robot actually clicks the buttons, types in the fields, and films itself doing it.

After the customer reported the ghost field, we did something that took about an hour: we scripted the robot to walk every money path we own. Every pricing tier. Both subscription products. The credit packs. The free-preview hook. Fifteen paths where a customer hands us money or an email address. The robot walked each one like a first-time visitor — clicked the real buy button, typed a real email, landed on the real Stripe page — and recorded all of it.

On the recording, the bug isn't subtle. The cursor moves to the field. The narration says "enter your email." And the field just sits there, blank, while the click track ticks. One frame. Obvious to anyone — obvious, crucially, to someone who doesn't know what was typed.

That's the insight we can't stop thinking about: a recording removes the tester's unfair advantage. The camera doesn't know what the robot typed. It only knows what the screen showed. Which is the only thing your customer knows, too.

Your tutorials should be your test suite

Every tutorial video on our CRM's site — all twenty-six of them — is produced by this robot. That started as a way to make videos that are never out of date: when the product changes, the videos re-record themselves.

But it quietly became something else. Those twenty-six scripts run against the live product. If a button moves, a modal breaks, a field dies — a video fails to record, and we know before any customer does. The marketing asset and the smoke test turned out to be the same artifact.

The checkout sweep made it official. The robot now walks our money paths and films the receipts: this price, this product, this email, locked, on Stripe's page, on camera. When we ship a redesign, we re-run the sweep and watch three short videos instead of hoping.

Most software teams treat demos and testing as separate universes — marketing makes videos, engineering writes tests, and neither watches the product the way a stranger does. A scripted browser with a camera does both jobs at once, and it does the one thing no insider can: it sees the screen without knowing what's supposed to be there.

The question worth asking

Somewhere in your product right now, there is probably a field, a button, or a step that works perfectly and shows nothing — or shows something so wrong that only a stranger would notice. Your tests pass. Your team knows the flow too well to see it. Your customers meet it alone, with their card out.

You could wait for the polite one in a hundred to email you about it. Ours did, and we're grateful.

Or you could point a camera at your money path and watch it get used by something that has never seen it before.

We know which one we'll be doing every release from now on.