"Let the Client Test It" Is an Engineering Failure

The very first production order on our own e-commerce store had the wrong amount. Unit tests all green, staging exercised countless times — and then the first real transaction in production hit two bugs that happened to mask each other, sailing through green lights all the way onto a customer's credit card statement. We learned something that day, in the most embarrassing way possible: a green light in staging only proves that staging works.

From that day on, "live" got a new definition on our team: not when the code finishes deploying, but when we ourselves have walked the entire chain end to end — with real money, real invoices, real logistics. Only then is it live.

What exactly is wrong with "let the client test it"

There's a very common phrase in this industry: "The features are done — please do acceptance testing." Sounds normal. But unpack it, and what it actually means is — whether the thing I built works, the person paying me should discover for themselves.

The client is not QA. They don't know they should verify that changing an order amount voids and reissues the government e-invoice. They don't know to open the page on a phone over 4G instead of office Wi-Fi. They don't know that after changing the amount on a convenience-store pickup order, the shipping number can't be reused. This is the engineering team's domain knowledge. Pushing verification onto people without that knowledge means sending bugs to find the person least equipped to handle them. And bugs love to appear precisely at the first real user, the first real order — exactly the moment that damages trust most.

Before delivery, be your own first user. Otherwise your client is your QA — and that's not what they're paying you for.

What our pre-launch culture looks like

Concretely, before any project ships, we walk through all of this ourselves — regardless of project size, with the same standard for a brochure site and an e-commerce system:

• End-to-end tests wired into CI. Not "we have tests," but simulated real-user flows from landing to goal completion, run automatically on every change. Humans forget to test; machines don't.
• At least one real payment through the live gateway. Our own credit card, real money — then check that the invoice was issued, the notifications fired, and the back-office numbers match. Test-mode and production payments are two different worlds; that's tuition we've already paid.
• Mobile checks on physical devices. Not a browser emulator — pick up a phone and open it on a mobile network. Font sizes, tap targets, load speed: emulators lie about all of them.
• Click every single link. This one has its own article: why we have a rule that links are never allowed to 404.

This discipline wasn't invented for client work. Our own product lines — an e-commerce store taking daily orders, an app on both stores, an inventory system supporting a franchise network — go through the same routine on every release. Precisely because the money and the customers that got hurt were our own, we welded it into the process instead of hanging it on the wall for show.

Discipline is expensive; incidents are more expensive

Honestly, these checks take time, and most of the time they "find nothing," which looks like wasted effort. But that's the nature of engineering discipline: its value shows up only on the one occasion something is wrong, and you never know which occasion that will be.

The first order should not be a debugging session; the first user should not be a tester. If you're evaluating development teams, ask directly: "Before launch, how far do you test it yourselves?" Whoever answers vaguely — vague is what your orders will be. To see what we've actually shipped, the work is here — and for every piece of it, we were its first user.