You just got the milestone email. The demo looked fine, the invoice is attached, and the vendor is asking for sign-off. But you have not actually read the code, and once you approve, the leverage shifts. That is the moment a custom software code review checklist earns its keep.
Reviewing code from an outside partner is different from reviewing your own team. You do not share their habits, their ticket history, or their unwritten conventions. You need a repeatable vendor code review process that produces evidence, not opinions, and that you can run in a few hours per milestone.
This guide gives you that checklist: what to inspect, what questions to ask, which red flags justify holding payment, and how to turn one review into a standard you apply to every delivery.
Key takeaways
- Review the repository, not the demo. A working feature built on unmaintainable code is a liability you inherit on day one.
- Split your review into four passes: structure, security, tests, and handover. Each has its own yes/no questions.
- Ask for evidence, not assurances. Coverage reports, CI logs, and dependency scans are cheap for the vendor and decisive for you.
- Put the checklist in the contract before work starts, so the review is a routine gate rather than a negotiation.
- Score findings by risk and tie milestone acceptance to fixing the critical ones.
Why outsourced code needs a different review lens
When your own engineers write code, context is implicit. You know why a shortcut was taken and who owns it. With an external partner, that context leaves with the contract. What remains is the artifact, and the artifact has to stand on its own.
Two failure modes show up repeatedly in outsourced delivery. The first is demo-driven development: the visible path works because it was polished for the review call, while error handling, edge cases, and logging are thin. The second is knowledge concentration: one contractor understands the deployment, and nobody else can reproduce it.
Both are invisible in a product demo and obvious in a repository. That is why a third party code audit checklist should always start with the code, not the software.
The four-pass custom software code review checklist
Run these passes in order. Stop early if a pass fails badly, because later passes assume the earlier ones are sound.
Pass 1: Repository and structure
- Is the full source in a repository you control or have admin access to, with a real commit history rather than one giant initial commit?
- Do commit messages describe intent, or are they all variations of "fix" and "update"?
- Is there a README that a new developer could follow to run the project locally?
- Are secrets, API keys, and credentials absent from the code and history?
- Is the folder structure consistent, or does it mix patterns from several abandoned approaches?
A single squashed commit is not automatically a problem, but it removes your ability to audit how decisions were made. Ask why.
Pass 2: Security and dependencies
- Are inputs validated at trust boundaries, or does user data flow into queries, shell commands, or templates unchecked?
- Are authentication and authorization enforced server-side, not just hidden in the UI?
- Do you have a dependency scan report, and are known-vulnerable packages pinned or upgraded?
- Are errors logged with enough detail to debug, without leaking stack traces or personal data to users?
- Is transport encrypted, and are stored credentials hashed with a current algorithm?
Security findings are the ones that justify pausing a payment. Everything else can usually be scheduled.
Pass 3: Tests, CI, and quality signals
- Do automated tests exist, and do they run in CI on every commit?
- Do the tests assert behavior, or do they simply execute code to inflate a coverage number?
- Is there a linter and formatter configured, and does the build fail when they are violated?
- Can you reproduce a build from a clean checkout using documented steps?
- Are there tests for the failure paths, not only the happy path?
You are not chasing a coverage percentage. You are checking whether the vendor can change this code safely after you take it over, and tests are the cheapest evidence of that.
Pass 4: Maintainability and handover
- Are modules cohesive, or is there a single file that everything depends on?
- Is configuration externalized, so environments differ by config rather than code edits?
- Is the data model documented, including migrations and rollback?
- Are third-party services and licenses documented, including any copyleft obligations?
- Is there a runbook for deployment, monitoring, and common incidents?
This pass answers the real question behind how to review outsourced code quality: could a different team pick this up next month without a handover call?
Questions to ask the vendor in writing
Verbal answers evaporate. Send these in email or your shared tracker so the responses become part of the record.
- What are the three riskiest parts of this codebase, and why?
- What did you deliberately not build yet, and what breaks if we ship without it?
- Which parts would you rewrite first if you had another sprint?
- What is your rollback plan if this deployment fails in production?
- Who on your team can answer questions about this code in three months?
Vendors who answer these candidly are usually the ones worth keeping. Vague or defensive answers are themselves a finding.
How to score findings and gate the milestone
Do not treat every issue as equal, or you will stall delivery on style preferences. Classify each finding into one of three buckets.
- Blocking: security holes, missing authorization, secrets in the repo, no reproducible build. Fix before payment.
- Conditional: thin tests, missing documentation, unclear error handling. Fix before the next milestone, tracked as tickets.
- Advisory: naming, formatting, minor refactors. Log them and move on.
Write the bucket into your acceptance criteria. A milestone is complete when blocking items are closed and conditional items have named owners and dates. That single rule converts code review from a debate into a process.
If you would rather have engineers who already work this way handle the build, our team does exactly that through our custom software development services, and you can see how the reviews look in practice in our past project work.
Build the checklist into the contract, not the argument
The best time to introduce a code review checklist is before the first line of code. Add it as an appendix to the statement of work: repository access from day one, CI from the first sprint, dependency scanning as a deliverable, and milestone acceptance tied to the blocking/conditional split above.
When the checklist is contractual, the review becomes routine. When it is improvised at the end, it becomes a dispute about scope. Teams that formalize code review standards for agencies early report far fewer surprises at handover, because expectations were set while everyone was still friendly.
If you are mid-project and the contract is silent, you can still introduce the checklist at the next milestone. Frame it as risk management, not distrust, and offer to absorb the cost of any blocking fixes that stem from ambiguous original requirements.
Make the review repeatable
One good review is a save. A repeatable review is a system. Store your checklist in the repository, version it, and refine it after each milestone based on what actually broke. Over a few deliveries, your checklist becomes a precise map of where this vendor, and this codebase, tend to fail.
Avaton builds custom software, AI systems, and blockchain products, and we are comfortable working inside a client's own review and audit process, or bringing our own. If you want a second opinion on a delivery before you sign off, talk to our team.
Frequently Asked Questions
How long should a vendor code review take?
For a typical milestone, budget a few hours of focused review across the four passes, plus time for the vendor to answer written questions. It scales with codebase size and risk, not with the invoice amount. If a review is taking days, your checklist is probably too granular.
What is the single biggest red flag in outsourced code?
No reproducible build. If you cannot check out the repository and run it from documented steps, you cannot verify anything else, and you are dependent on the vendor for every future change. Treat it as blocking.
Should I require a minimum test coverage percentage?
A coverage number alone is a weak signal, because tests can execute code without asserting anything meaningful. Ask instead for tests on critical paths and failure cases, and for CI that runs them on every commit. Coverage is a supporting metric, not the goal.
Can I run this checklist if I am not technical?
Yes, partially. You can verify repository access, documentation, dependency scan reports, and CI logs without reading code. For the security and architecture passes, bring in an independent engineer or a fractional CTO for a few hours per milestone.
How do I raise code quality concerns without damaging the relationship?
Anchor every point to a written standard agreed in advance, and separate blocking issues from advisory ones. Vendors respond well to specific, evidence-backed findings and poorly to general complaints about quality. Keep the tone collaborative and the criteria objective.
Cover: Photo by Jakub Zerdzicki on Pexels