The demo works. The developer who built it runs it, clicks through it, nods, and says it is done. You accept it. Three weeks later the invoice flow breaks on the one case nobody tried: two people editing the same record at once.
Nothing malicious happened in that story and nobody was lazy. One human checked their own homework, which is the one check humans are bad at. The fix is not working harder. It is structural.
The rule and why it works
At Anito, nobody signs off on their own work. The person who accepts a feature is not the person who built it, and QA sits outside the build team entirely. The rule is cheap to state and does its work in a specific moment: the moment the builder’s certainty meets a second person’s fresh eyes.
Fresh eyes find what certainty hides. The builder knows what the feature is supposed to do, so their clicks follow the happy path. A second person asks what the unhappy path looks like: two users at once, a network drop mid-save, a file with the wrong shape. Those are the cases that reach your customers, because they are the cases the happy path never meets.
What acceptance should look like
The rule extends past QA to you, the payer:
- You review working software, not reports. Working features land in a test environment (a private copy of the system) that your team opens themselves. If acceptance happens over screenshots, you are accepting a story about software, not software.
- Findings are in writing. QA runs the agreed workflows and the failure cases, and writes down what broke. A written finding is checkable, debatable, and survives the project. “It feels solid” is none of those.
- Acceptance has a written basis. You accept against the agreed scope and the written findings, so the sign-off is a documented decision, not a developer’s assurance with your name attached.
- The open-items list ships with the acceptance. What is done, what is not, and what it will take. A handover without an honest still-open list is a handover with a surprise invoice inside it.
Where the scars come from
I ran the technical support team at Pantheon, the platform hosting large-scale sites, for four years. The tickets taught me which part of a failed launch bites first, and it is rarely the part people expect: the launch works, the demo worked, and the first real Tuesday breaks it, because Tuesday brings the concurrency, the bad data, and the user nobody scripted. That career is checkable; the lesson from it is on this page because it saves you the expensive version (this is the founder writing, and the career is on LinkedIn and the about page to be judged, not believed).
The discipline shows up in what we publish, too. Our FMMS product (a facilities maintenance system) is a working demonstration with zero deployments, and we say that plainly, because a demonstration labeled as a demonstration is worth more than a claim dressed as a client. Every project on our portfolio carries its status for exactly this reason.
The check
- Ask any developer you are quoting with: “who signs off on the work, and did they build it?” A one-sentence structural answer means the practice exists. A pause means you just found your risk.
- Ask: “can I see findings in writing from your last build?” Real QA produces documents the way construction produces dust.
- Ask: “where do I log in to review work before accepting it?” You want a link you control, before invoice one, not after.
- Ask: “what is still open after this invoice?” The builder who answers with a list is the one who knows the answer.
Support and handover are where this rule pays out last: the written findings and the honest open-items list are what make leaving cheap, which is what makes staying meaningful. Our guide to when your developer disappears covers the version of this you get to do alone, and our process page shows the review and acceptance steps in order. If a current project has no second pair of eyes on it, discuss your project with us. We will tell you what a review pass should include, and you can hand that list to whoever you like, including someone else.
Common questions
Does a second reviewer slow the work down?
It moves the slowness to where it is cheap. A review pass takes minutes to hours. The bug it catches takes days, arrives in production, and bills you twice: once to find it under pressure and once to rebuild the trust it spent. Teams that run outside QA ship at a comparable pace with fewer surprise invoices, and the surprises they do get are smaller.
What does QA actually test, day to day?
Two lists. The agreed workflows (the paths your business runs every day: order in, invoice out) and the failure cases nobody scripted: double submissions, missing fields, two users colliding, a network drop mid-save. The first list proves the system works. The second list proves it survives. A QA pass with only the first list is a demo with paperwork.
What is a test environment, in plain words?
A private copy of your real system, on its own address, where new work lands before customers can reach it. Your team clicks through it at their own pace. It differs from the live system in one way that matters: mistakes there cost nothing. Any build you pay for should hand you a login to one before the first acceptance.
We already launched without any of this. Is it too late?
No, and the honest sequence starts with a review pass over what is live: the workflows that make or lose money first. You get a written findings list, you fix by priority, and the structural rule starts applying from that day forward. Rescue work of that kind is a service we offer, and a second pair of eyes you can hire for a review alone, even when the building stays with someone else.