How to Review Contractor-Delivered Code Before You Accept It

When a contractor delivers code, acceptance review is not the same as reviewing a teammate's pull request. You are checking whether what you paid for is something you can own, extend, and keep running after the contractor is gone. The person who wrote it will not be around to explain it. So you review for handoff quality, not just correctness: can your team understand this, run it, change it, and trust it without the author in the room? Most acceptance reviews skip that question and pay the invoice on a green demo.

Why a working demo is not acceptance

The demo proves the happy path works today. It proves nothing about the six months after the contractor moves on. Contractors are paid to ship a deliverable, and the incentive is to make it look done, not to make it maintainable by someone else. That is not malice. It is the shape of the engagement.

So separate two questions. Does it work? And can we live with it? A slick demo answers the first. Only a real code review answers the second, and the second is the one that costs you if you get it wrong. I have inherited contractor code that demoed perfectly and turned out to be an unmaintainable knot the moment we needed to change it.

What to check before you sign off

Start with the boring things that predict pain. Can a new engineer clone it and run it from a README, or does it only work on the contractor's machine? Undocumented setup is a red flag that says the code was never meant to leave. Read the commit history if you got the real repo, because git history reveals red flags that the final snapshot hides: one giant commit at the end means no incremental discipline.

Check the tests. Not the count, the substance. Do they assert real behavior or just that the code runs? Look at the dependencies, because you inherit every one, and an abandoned or unpinned tree is your problem now. Run a structural pass the way you would when scoring a repository you did not write, because you are in exactly that position: reviewing code with no author to ask.

The parts contractors quietly cut

There are predictable corners. Error handling is often missing, because the happy path demos and the failure path does not. Configuration is frequently hardcoded, because parameterizing takes time the contractor was not paid for. Secrets get committed. Logging is absent, so when it breaks in production you are blind. Documentation is a thin README written in the last hour.

None of these show up in a demo. All of them show up the first time something goes wrong at 2am and the contractor is on a different project. Make the review find them now, while you still have leverage, meaning while the final payment is still yours to hold. A repo intelligence scan surfaces the coupling, dead code, and hotspots fast, so your acceptance review aims at the real weak points instead of skimming.

Bake the standard into the contract

The cleanest fix is upstream. Define acceptance criteria before the work starts, not after delivery. Specify that the repo runs from a documented setup, ships with tests that assert behavior, pins its dependencies, commits no secrets, and includes a handoff document. Then acceptance is a checklist, not an argument. This is the same discipline as writing acceptance criteria for AI coding agents: the deliverable is defined by what it must satisfy, and review is verification, not negotiation.

When the standard is written down, you also protect the relationship. A contractor who knows the bar going in usually hits it. The fights happen when the bar is discovered at delivery. And if the contractor is an agency you will use again, hold them to it consistently, because a vendor who learns you actually check will deliver better code the second time.

What acceptance actually protects

The goal is not to catch a contractor doing bad work. It is to make sure the thing you now own is something you can own. Code you cannot run, understand, or change is not an asset. It is a liability with a green demo attached. Review contractor-delivered code for the day the contractor is gone, because that day is coming, and by then the invoice is paid and the leverage is gone. Do the review while you still hold both.