How do I know my developer built what I asked for?

Check the finished software against acceptance criteria you agreed before the build started. Each requirement gets a clear pass or fail, and the people who do the work try it with real cases, including the awkward exceptions.

If "what I asked for" was never written down in checkable form, there's nothing objective to check against, and the conversation turns into opinions.

What should I check against?

The approved specification, and in particular its acceptance criteria. For example: "Given an order that would put a customer over their credit limit, when it's entered, then it's saved on hold and the credit manager is notified." You can try that and see.

If you don't have acceptance criteria yet, write them now, before you test, and agree them with the developer. That's better than arguing afterward.

Who should do the checking?

The people who supplied the knowledge. Finance should try the credit rules; dispatch should try the delivery scheduling. They know the exceptions, and they'll notice when something is technically right but wrong for the way the work is done.

What should we test besides the happy path?

• The exceptions your staff handle from memory.
• Edge cases: exactly at a limit, a blank field, a duplicate record.
• Permissions: someone trying to see or change what they shouldn't.
• What happens when a connected system is unavailable.
• Real data volumes, not just a handful of test records.

How do I track it?

A simple list: each requirement's ID, its acceptance criteria, pass or fail, and notes. Anything that fails goes back to the developer with the ID and what happened. Anything that passes but turns out not to be what the business needs is a change, not a defect, and should be handled as one.

What if the developer says it matches the spec, and we disagree?

Go back to the words. If the specification and its criteria are clear, the answer usually is too. If they're ambiguous, settle what was meant, record the decision, and agree whether it's a fix or a change. Clear criteria up front prevent most of these disputes.

Can AI coding tools check their own work?

Partly. With clear acceptance criteria, a tool can write automated tests and run them. People still need to try the software, because tests can only check what someone thought to write down.

A Mochlion Build Specification includes acceptance checks and tests for its requirements, each traced to the requirement it verifies; the sample shows how.