This week I finished a small tool that files client messages automatically. A client drops a photo, a voice note, or a quick update into a private group, and it lands in the right folder without anyone lifting a finger. Before I handed it over, it passed every automated test I had written for it — 26 out of 26, all green.
Then a fresh reviewer who had not built it looked at it and found a real flaw in minutes. That gap between "passes my own tests" and "actually works" is the most useful lesson I can pass on this week, and it applies far beyond software. If you run a business, you need an independent quality check on anything important before it goes out the door.
Why passing your own tests isn't proof
Here is what happened. My tests all passed because they ran against a stand-in — a fake version of the outside service the tool talks to. And my fake behaved perfectly. But the real service does something different when a file is too big: it rejects the request instead of accepting it. My tool had no plan for that case, so in the real world it would have quietly tried the same message over and over, forever, with nobody noticing.
Every one of my tests said "you're ready." They were wrong — not because I was careless, but because I tested against my own assumptions. The blind spot that made me miss the flaw was the same blind spot baked into the test I wrote to catch it.
This is the trap. When you grade your own work, you grade it against what you expected, not against what's real. If you missed something while building, you'll usually miss it again while checking.
What an independent quality check actually catches
The reviewer wasn't smarter than me. They just came in cold, with different assumptions, and asked one question I hadn't: what does the real thing do when something goes wrong? That question is exactly the one a builder skips, because in your head the thing already works.
An independent check catches three things your own review misses:
- The case you didn't imagine. You can't test for a problem you don't know exists.
- The stand-in that behaves too well. In a rehearsal, everything cooperates. Real customers, real suppliers, and real payments don't.
- The "it's obviously fine" step. The parts you're most confident about are the parts you check least.
None of these show up when the person who built it is also the person who signs off.
How to build this into your own business
You don't need a QA department. You need to separate the doer from the checker on anything that would hurt to get wrong. A few ways I do it:
Have someone who didn't do the work sign off
The person who wrote the proposal shouldn't be the only one who proofreads it. The person who packed the order shouldn't be the only one who confirms it's right. A second set of eyes with no stake in "it's done" is worth more than three passes from the person who made it.
Test against the real thing, not a friendly rehearsal
A menu that looks great on your laptop can break on a customer's phone. A refund policy that reads fine in a document can confuse someone at checkout. Whenever you can, check under real conditions, not the comfortable ones you set up yourself.
Ask "what happens when it fails?"
Most things work when everything goes right. The damage happens when a file is too big, a payment bounces, or a customer says something you didn't plan for. Walk through the failure, not just the success.
The flaw in my tool would have been invisible until a client sent one oversized video — and then it would have jammed silently. Catching it cost one fresh review. Missing it would have cost a client's trust.
Passing your own tests feels like proof. It isn't. The check that matters most is the one done by someone who didn't do the work.