Reviewing handed-over code — is there a code review checklist for non-developers?

The single most critical issue is independence. Can the code run on your servers without relying on any of the agency's external servers, their proprietary developer accounts, or their staff's personal email addresses? If a third-party notification service or server key is tied to their account, your system will eventually get locked out down the line.

Even without technical know-how, you can still run automated code scanning tools. Enable the free security scanning built into your code repository. These tools generate a report listing exposed vulnerabilities and outdated packages; you can just hand that report straight to the agency and tell them to clean it up.

We made this exact mistake last year on a similar $40,000 handover. We thought we had the code, but not a single automated test had been written. The incoming team asked for an extra $12,000 and 6 weeks just to understand the architecture and write tests. Definitely check whether there is a test directory in the repo and if it actually has content.

A manager visually scanning the repository only gives you a false sense of security. You can't catch a hidden memory leak or an unoptimized database query just by looking at file names. Paying your newly hired team $500–$1,000 to produce a written technical handover report is a much more foolproof approach.

Jump on a 1-hour screen share with your new freelancer first thing tomorrow. Have them spin up the system from scratch, restore a database backup, and perform an action in the admin dashboard. If they can pull that off, you can safely release the final payment.

Everything looked spotless when our former agency handed off the project. Two months later, after updating our DNS records, we discovered the third-party notification integration was tied to the agency owner's personal credit card. When that card was cancelled, all our notifications went down. Make sure all third-party service accounts are transferred to corporate emails owned by your company.

check the latest commit dates in the repo too imo. I mean if they pushed a thousand files at once two days before the contract ended they probably rushed to close it out and dont even know whats in there themselves.

Edit: asked below, I wrote the answer in the second message.

I recommend reviewing the intellectual property transfer terms in your contract. Even if the code has been delivered, legal ownership disputes can still arise unless a formal IP assignment and release agreement is signed. You should handle the technical verification and legal sign-off in tandem.

Sorry, but this doesn't apply in every case. Don't hesitate to ask; those who don't ask always pay more.

Implementing a change request process doesn't slow things down, it speeds them up. Hope this helps.

don't miss this: Everyone rushing into surce code review checklist gets stuck at the same point.

this is my opinon I'm not claiming it's absolute truth.

I felt relieved reading this answer, so it's not just me. Everything goes well for the first three months; problems arise in the fourth.

Of course, it varies if your situation is different.

The answer above hits the nail on the head. like if scope grows, either time or budget must grow. There is no third option.

Im also curious if anyone does it differently.

Correct in theory, but it doesn't work that way in practice. Everything goes well for the first three months; problems arise in the fourth.

Correct me if I'm wrong.

I'll try it.

The discussion got scattered, let me summarize. If acceptance criteria aren't written when the work is done is open to debate.

I'm writing this so you don't make the same mistake. Access credentials should be opened in the company's name, not personal accounts.

When making a decision, first look at what data you have on hand.

Sorry, but this doesn't apply in every case. The cheapest quote is usually the least thought-out one.

Correct me if I'm wrong.

Just a heads-up. When making a decision, first look at what data you have on hand.

If I were you, I'd go this route.