How to Accept Outsourced Software Delivery: A 12-Item Checklist

Toward the end of a project, neither side feels comfortable. The client wants to see the finished system; the vendor wants to close the invoice. How to accept outsourced software delivery looks like a technical question, but it is really a contract execution question. Whether acceptance criteria were settled at kickoff determines whether the project ends in a smooth handover or an argument.

At Juhui Software we have both built projects and supported clients through their acceptance reviews. We have watched too many projects stall in the final two months: every feature was built, but the source code, deployment documentation and account credentials were never handed over. Everything ran in the vendor's demo environment and then failed to start on the client's own servers. This guide breaks acceptance into three parts: the deliverable checklist, the acceptance criteria, and the practical test sequence.

1. A checklist of 12 standard deliverables

The first layer of outsourcing delivery acceptance is confirming that everything has actually been handed over. The following is the standard deliverable list Juhui Software typically attaches to contracts. Twelve items; record any that are missing.

• Source code with complete version control history across all branches;
• Reproducible build instructions listing environment dependencies and compile commands;
• Database schema documentation and creation scripts with field comments;
• API documentation covering request parameters, response structures and error codes;
• Deployment documentation covering server configuration, dependent services and release steps;
• UI design source files and exported assets;
• Test cases and a test report including the list of fixed defects;
• A known issues list with a handling plan;
• An inventory of third-party accounts, keys, domains and related resources, with a transfer record;
• User manuals and training material, including back-office operating instructions;
• Data initialisation scripts and the results of historical data migration;
• The interactive prototype and the final confirmed requirements document.

Items five and nine are missed most often and cause the most downstream disputes. Missing deployment documentation means going live depends entirely on the original vendor. Untransferred account credentials mean the client never truly owns the system and must keep paying to keep it running. Both must be confirmed physically at the acceptance meeting, not accepted as a verbal assurance that they are included.

2. Three levels of acceptance criteria

Once the deliverables are confirmed, the second layer is whether the functionality meets what was agreed. Three levels make the judgement objective and avoid the vague verdict of "roughly working".

The first level is functional consistency. Every delivered feature must correspond point by point to the confirmed requirements document, and each one must be demonstrated as working. It helps if the client's own business staff pre-test against the feature list before the meeting and mark the disputed items, so the acceptance session addresses disagreements directly instead of watching a vendor demo from start to finish.

The second level is quality thresholds, which need to be measurable. For example: all P0 defects on core flows closed, no more than an agreed number of P1 defects with a clear remediation plan, performance meeting defined concurrency or response time targets, and compatibility covering the device models and OS versions the client actually uses. Without quantified criteria, acceptance turns into subjective bargaining.

The third level is sustainability. The system must be maintainable by the client's own operations staff: readable code structure, adequate comments and documentation, a reproducible environment, and monitoring and logging in place. Many projects ignore this level entirely, which leaves the client unable to safely modify or extend the system after handover. In practice they have not taken ownership at all.

3. A practical acceptance test sequence

A well-run outsourcing delivery acceptance test usually follows five steps within three to five working days.

Step one, environment setup. The client deploys independently in its own test environment, not in the vendor's demo environment. The deployment is itself a test: if the deployment documentation cannot get the system running standalone, the documentation does not count as delivered.

Step two, functional walkthrough. Each item on the requirements list is executed by the acceptance team, recording one of three states: pass, defect, or to be clarified.

Step three, defect reproduction. Problems found during the walkthrough are logged on the spot with reproduction steps, actual result and expected result, forming a defect list with agreed fix dates and a regression check after fixes.

Step four, documentation and resource check. The 12-item list above is verified item by item, including document completeness, and the usability of accounts and keys. Demonstrate login access and an actual API call using the transferred credentials.

Step five, written conclusion. Produce an acceptance report with one of three outcomes: pass, conditional pass with listed residual issues and remediation deadlines, or fail, along with the corresponding treatment of the final payment. All three should be pre-agreed options in the contract rather than improvised on the day.

4. Seven clauses that belong in the contract

Most acceptance disputes originate in the contract rather than in execution. Put these seven clauses in place and outsourcing delivery acceptance is largely under control:

• Which version of the requirements document governs, and how the acceptance basis is updated after a change;
• Who participates in acceptance and what each party's responsibilities are, with business, technical and operations staff all represented on the client side;
• Who provides the acceptance environment, and whether the client has independent deployment rights;
• Defect severity definitions and the remediation deadline for each level;
• The deliverable list and the handling procedure when an item is missing;
• The final payment ratio mapped against each stage acceptance checkpoint;
• How many remediation rounds are allowed after a failed acceptance, who bears the cost, and how the process concludes if it still fails.

The one most often overlooked is who participates. With only business staff present, many technical issues get waved through. With only technical staff present, misunderstandings about business rules survive until after launch. Ideally all three client roles attend, each responsible for what they understand.

5. Lessons from real projects

First, never look at the system for the first time during outsourcing delivery acceptance. Juhui runs a mid-project acceptance that walks the deliverable list and rehearses the acceptance process. Problems found there cost nothing, because development time remains; problems found at the end multiply both fix and communication cost.

Second, verify source code handover by compile, not by file transfer. Have the vendor clone the repository from an empty directory and complete a full build during the acceptance meeting. It takes under half an hour and prevents the client from receiving historical code that does not compile.

Third, record the credential handover in a signed checklist and have the vendor change passwords or revoke their own access afterwards. This guarantees the client has complete access while preventing a former vendor from retaining access to the client's production data.

Fourth, document residual issues in the acceptance report. Passing with three known issues is perfectly normal; what matters is that each issue has a stated impact, an owner and a fix date linked to the payment schedule. Issues left verbal have not been recorded at all.

How to accept outsourced software delivery comes down to aligning both parties' expectations at the start. The longer the project and the more requirements change, the more firmly the acceptance criteria must be fixed in the contract. A good acceptance meeting depends on a clear checklist, a process that has already been rehearsed once, and documentation that genuinely works when followed. With those three in place, acceptance stops being a negotiation and becomes a confirmation.