Why the demo tells you almost nothing

Every vendor pitch shows you the happy path: the feature working exactly as intended, on exactly the data they chose, in exactly the order they rehearsed. That tells you the team can build something that works when nothing goes wrong. It tells you nothing about what happens the one time in a hundred when someone on your team fat-fingers a field, clicks the wrong row, or tries to do the right thing in the wrong order - which, at any real scale, is not a hypothetical. It's Tuesday.

The better question isn't "does it work?" It's "what does it do when I try to make it fail?" Good engineering teams have a name for the discipline that answers that question: mistake-proofing, or by its original Japanese name, poka-yoke - literally "error-avoiding." It comes out of Shigeo Shingo's work on the Toyota Production System in the 1960s, and the idea is deceptively simple: instead of training people to be more careful, you change the design of the process so the mistake becomes physically or procedurally impossible to make in the first place.

The physical world already runs on this - you just don't notice

Mistake-proofing is easiest to see in hardware, because the constraint is visible and mechanical. None of these are edge cases the manufacturer bolted on for compliance - they're the default expectation of a well-engineered system:

Reverse lockout at speed

Most modern automatic and CVT transmissions read vehicle speed and simply refuse to engage reverse gear above a few kilometers per hour - the shift request is accepted by the lever, but the transmission control unit won't act on it until speed drops to a safe range.

Weight-on-wheels gear interlock

Commercial aircraft use a squat switch on the landing gear strut to detect whether the plane is on the ground or airborne, and that single signal blocks the crew from retracting the gear while weight is still on the wheels - a mechanical fact overriding a possible human command.

Spin-cycle door lock

A washing machine's door interlock won't release mid-spin regardless of what button you press, because the one action a user might take by reflex - opening the door - is exactly the one the system is designed to physically prevent until the drum has stopped.

Notice the pattern across all three: none of them stop the user from trying. The lever still moves, the button still exists. What's blocked is the system acting on that input until a precondition (speed, altitude, drum speed) makes the action safe. That distinction - block the effect, not the attempt - is exactly what carries over to software.
THE MISTAKE-PROOFING GATE User attempts the action shift · delete · resubmit System checks the precondition speed? confirmed? seen before? met fails Action executes safely Blocked - nothing changes

The same gate structure runs underneath every example in this piece, physical or digital: check the precondition first, then either let the action through or stop it cold - never punish the attempt itself.

What the same discipline looks like in software

A good IT company applies the identical logic to digital systems, and it shows up in specific, checkable places rather than as a vague promise of "quality." These are the patterns worth looking for:

Typed confirmation for irreversible actions

Deleting a production database, a customer account, or a paid invoice shouldn't yield to a single click. Requiring the user to type the resource's name or the word "DELETE" turns an accidental double-click into a deliberate act - the same principle as a fuel cap you have to twist, not just push.

Human approval before high-stakes autonomy

Any system that acts on your behalf - an automation, an AI agent, a scheduled batch job - should pause for a named person to approve the step where a mistake is expensive, and log who approved it. Full autonomy on low-stakes steps, a gate on the ones that aren't.

Sequence enforcement in the workflow

An order shouldn't be printable before it's opened and confirmed; a refund shouldn't post before it's approved; an invoice shouldn't send before line items are reviewed. The UI should make the out-of-order action unavailable, not just log a warning after the fact.

Idempotent handling of retries

Networks fail and users double-click. A well-built payment or notification handler recognizes a repeated request as the same request, not a new one, so a retry can never charge a card twice or send a duplicate confirmation - a five-line check that prevents an entire category of incident.

Soft delete with a recovery window

The best-designed systems don't let "delete" mean "gone forever" by default. A recoverable trash state with a defined retention period turns an accidental delete from an incident into a two-minute restore, at the cost of a little extra storage.

A tested rollback path before go-live

Before anything reaches production, a mature team can already answer "how do we undo this in five minutes if it's wrong?" - not as a hypothetical, but as a documented, rehearsed step with a named owner.

Why most teams skip this - and why it costs more later

None of the patterns above are exotic or expensive to build. A confirmation dialog, an idempotency key, a soft-delete flag, and an approval gate are each a few hours of work for a team that thinks to add them. The reason they're often missing isn't difficulty - it's that they don't show up in a feature list, a demo, or a scope document unless someone explicitly asks. They're the kind of quality that's invisible until the day it isn't, and by then the cost has shifted from a design decision to an incident: reconciling duplicate transactions, restoring from a backup, or explaining to a customer why their account was deleted with no way back.

This is also why "the team moved fast" and "the team engineers to prevent mistakes" are not in tension. Mistake-proofing isn't extra process bolted onto a build - it's a small, specific set of design decisions made once, at the point where the risky action is first built, that keep paying off every time someone almost gets it wrong.

The audit you can actually run on a vendor

You don't need to read code to apply this test. In your next demo or discovery call, ask the vendor to show you - live, not described - what happens when you try to do each of the following:

  • Delete or archive something important. Does it ask you to confirm in a way that's hard to do by accident, and can you get it back if you change your mind?
  • Submit the same form twice in a row, quickly. Does it create two records, charge twice, or send two emails - or does it recognize the repeat?
  • Try to do a step out of order - print before confirming, approve before reviewing. Does the interface stop you, or just let you and log it afterward?
  • Ask what happens if an automation or AI feature gets a step wrong. Is there a human checkpoint before the consequential action, or does it run end-to-end unattended?
  • Ask for the rollback plan for their last production release. A specific, rehearsed answer is a good sign; "we'd figure it out" is not.

A team that has already thought about these questions will have concrete, specific answers, often with a screen to show you. A team that hasn't will improvise an answer in the moment - and that improvisation is itself the signal, because it tells you these questions haven't come up before, which means they haven't been designed for yet either.

Key takeaways

  • A demo shows you the happy path; mistake-proofing shows you what a vendor built for the path where something goes wrong.
  • Poka-yoke's core idea - block the effect, not the attempt - works identically in hardware and software.
  • Look for confirmation gates on irreversible actions, human approval before high-stakes automation, enforced workflow sequencing, idempotent retry handling, recoverable deletes, and a rehearsed rollback plan.
  • These patterns are each cheap to build proactively and expensive to explain away after an incident.
  • The fastest way to evaluate a vendor is to ask them to show you - live - what their system does when you try to break it on purpose.
We apply every one of these patterns as a non-negotiable standard on our own builds, not an upsell - see how they show up in our AI agent work and enterprise AI rollouts, where a human approval gate and a tested rollback plan are part of the delivery model itself, not an afterthought.