I've been building a research assistant for a glass manufacturer I work with. When a restaurant owner books a consultation, the tool studies the venue overnight and hands the design team a one-page brief before the call. This week it taught me something about quality control that applies to any business, not just software.
It caught its own mistake. And it almost shipped it anyway.
The mistake a "passing" check let through
The tool measures each building two separate ways, from two independent sources. On one real restaurant, the two numbers disagreed badly. One source pointed at the actual building. The other pointed at a nearby bus shelter — and reported the restaurant as a 56-square-foot box.
Here's the part that stayed with me. The system noticed the disagreement. It had a step whose entire job was to flag exactly this. That step did its job. It raised its hand and said, "these two numbers don't match."
And then nothing happened. Nothing was listening. The flag got raised into an empty room, the brief kept going, and the architect would have walked into a call believing a real restaurant was the size of a phone booth. On a run that looked, from the outside, like everything passed.
Why "we double-check" isn't a quality control system
Every business owner tells themselves they have quality control. You proofread the invoice. You glance at the order before it ships. A staff member reviews the work.
But look closely at what usually happens. The check gets done. Someone reads the thing. The problem is that reading it and acting on what you read are two completely separate jobs — and most quality control quietly skips the second one.
- The proofreader spots the typo but the file was already sent.
- The manager sees the order is wrong but the truck has left.
- The system flags a mismatch but nothing stops the work.
A check that finds a problem and doesn't halt anything isn't quality control. It's a smoke detector with the battery pulled out. It beeps into nobody's ears.
The question that turns a check into a real safeguard
After this, I rebuilt the tool so a disagreement between its two measurements is a hard stop — the whole brief refuses to file until a human looks. Not a note in a log. A locked door. Here is the simple test I now run on any check, in any part of a business.
Does something act on the answer?
If the check can flag a problem and the work keeps moving anyway, it is decoration. Wire the flag to a real consequence: the shipment holds, the send button greys out, the file won't save.
Does it stop the work, or just record it?
A note you'll "review later" is a note you'll never review. The strongest checks don't warn — they block. It should be easier to fix the problem than to bypass it.
Does a fix flow all the way through?
When I first corrected that building's location, everything downstream was still using the old, wrong spot — so a different fact silently vanished from the brief. A correction that doesn't travel the whole way is a brand-new bug wearing the old one's coat. Fix it once, and make sure every step that depended on it updates too.
The takeaway
Finding your mistakes is the easy half of quality control; the hard half is building a process that refuses to move until someone acts on what was found — so start by asking, of every check you already trust, "and then what happens?"