Shipped doesn't mean reliable: how I verify what I build for you

A vendor tells you "it's done." How do you know it actually works — not just in the demo you were shown, but in the cases nobody thought to test: two actions happening at the same instant, a connection dropping at the wrong moment, a screen refreshing a second too early?

Most of the time, you don't know. You trust, and you find out about the problems when your own users find them first. Here's how I avoid that.

The real problem: "done" and "reliable" are two different things

A feature can look finished — the screen renders, the button does something — without being reliable in real conditions. The gap almost always hides in what nobody thought to check: what happens if two people act at the exact same moment? If the page reloads before an error message has been read? If data that was supposed to be protected ends up visible anyway?

These are exactly the cases a quick glance at the screen never reveals.

The Foyer method, in one idea

The core principle is simple to state, yet rarely applied with discipline: never my own judgment alone, never the AI assistant's alone — always an external tool that checks the result, at every step.

In practice, every stage of work follows the same cycle: design, build, look at the result, have a tool objectively verify it actually works — not an impression, a mechanical check — then improve before starting again. It's that fourth step that changes everything: it takes the question "does it actually work?" out of the hands of whoever just built it.

Before any decision that commits you, I ask myself a simple question: could I answer for this, to you, if it goes wrong? That question is the real safeguard. What it guards against isn't incompetence — it's the erosion of vigilance: becoming, over time, comfortable enough to stop checking. The method exists precisely so verification stays a mechanical reflex, not a good intention that fades.

Proof rather than trust on faith

A report that says "everything's green" doesn't prove much if nobody can independently review it. On a recent project, I pushed this logic all the way: the most sensitive user journeys are filmed, at human speed, against the real system — not simulated, not sped up into something unreadable.

The most telling journey is filmed with two screens side by side, because what proves reliability isn't what one person does, but what the other person sees while it happens: does sensitive information stay invisible for as long as it should? Does each side learn what just happened without having to refresh the page themselves?

A detail that matters as much as the rest: when a journey hasn't been filmed yet, I say so explicitly, rather than letting it look like it never existed. Incomplete but honest proof beats proof that hides its gaps.

A real defect found, not a theoretical example

Here's something this process actually caught on a recent project, before any user ever saw it: after a match had gone to someone else, a message explaining what happened would display correctly — then an automatic screen refresh would erase it before anyone had time to read it. The person affected would have been left with no explanation at all.

That's not the kind of defect you catch by reading code or clicking a button once. It's the kind you only see by replaying the full scenario and actually watching it unfold. That's exactly what systematic verification is meant to catch — and exactly what it did here.

What I also tell you when something isn't working yet

The method doesn't claim perfection: it demands honesty about its limits, not hiding them. On that same project, a piece of data that should never have ended up in a document meant to be made public had slipped in. I spotted it, fixed it — and, more importantly, turned it into an automatic check that now blocks any publication containing that type of data. That check immediately caught a second occurrence nobody had noticed.

That's the response the method requires after a mistake: not just fixing it, but turning the vigilance that caught it into a barrier that no longer depends on someone's memory.

Why it matters to you

• You don't need to read code to be reassured — the proof is filmed, not just asserted.
• The defects invisible at first glance are exactly what the method targets first — that's precisely where bad surprises in production hide.
• Honesty about limits is part of the deliverable, not just the result that works.
• Human judgment stays where it matters — at the decisions that commit you — while verification itself runs continuously, without letting up.

It's this same method, with the same rigor, that I apply to every engagement — contact me if you'd like to discuss it for your project.