Software subcontractor acceptance checklist for primes

Accept a software increment when the agreed behavior works in the agreed environment and the evidence needed to operate it has been delivered. A demo alone cannot establish that. Define the acceptance scenario, dependencies, reviewer, and required artifacts in the scope before engineering starts.

This checklist is for a prime contractor assigning an application or integration work package to a software subcontractor. It is an engineering review aid. Your subcontract determines payment, formal acceptance, and remedies; keep those terms aligned with the technical review.

What should a software acceptance package contain?

Keep the package proportionate to the increment. A change to a validation message should not require a new architecture report, but it should identify the changed behavior and its verification. A new identity integration needs more evidence because more can fail at that boundary.

Write criteria around a workflow, not a percentage complete

“Scheduling module 90% complete” leaves the reviewer guessing what remains. “An authorized operator can assign an available aircraft to a qualified crew, and conflicting assignments are rejected” identifies behavior that can be demonstrated and tested.

Rainier's Vennli engagement provides a relevant domain: we delivered a flight scheduling portal under subcontract, including a Python domain model and a React/Material UI interface. The following scenarios are illustrative review criteria for that kind of system, not a reproduction of the client's requirements or test results.

Agree the details before implementation: which intervals conflict, which permissions apply, what happens after rejection, and which environment is representative enough to review. These decisions belong beside the scenario, not in a chat thread that the next reviewer cannot find.

Who owns integration dependencies?

Name an owner for each boundary. If the prime supplies identity, the subcontractor needs the authentication protocol, role mappings, test identities, and an available integration environment. If another supplier owns a source API, record its version, failure behavior, and change process.

Separate a demonstrated result against a stub from a demonstrated result against the actual integration. Both are useful, but they answer different questions. Record the outstanding integration check and who must unblock it; do not silently treat the stub result as final system acceptance.

A simple dependency register needs five columns: dependency, owner, expected interface, required date, and current limitation. Review it alongside the increment so unavailable access does not first appear as a delivery dispute.

What should the receiving engineer be able to reproduce?

Start from the delivered revision in a clean checkout. The receiving engineer should be able to identify required runtime versions, install dependencies, run the relevant tests, and follow the deployment instructions without borrowing the developer's laptop state.

The handover should identify:

• The repository, revision, build artifact and environment being reviewed.
• Configuration variable names and where authorized staff obtain their values. Keep credentials out of the instructions and repository.
• Database migrations, compatibility assumptions, backup prerequisites, and a recovery approach when reversing a migration is unsafe.
• Test data that can be used in the review environment without copying sensitive production records.
• External dependencies, license information, and any supplied components whose rights need separate treatment.
• Known limitations, unresolved findings, operational ownership, and the next review date.

Ask someone other than the implementer to follow the instructions. A successful walkthrough by the author can conceal missing setup steps that become expensive during transition.

How do you handle findings without losing track of acceptance?

Keep a short decision record for each reviewed increment. Identify the scenario, result, evidence location, finding, owner, and agreed next action. Distinguish a failed requirement from a new request: the distinction affects both engineering priorities and the commercial conversation.

For an illustrative release, the record might say that assignment validation passed but the keyboard error announcement failed. Record the accessibility finding and its owner rather than summarizing the entire release as “tested.” The designated acceptance authority then applies the agreed contract terms to the remaining work.

Tie automated results to the delivered revision. If a fix changes the behavior under review, rerun the affected checks and preserve enough context for the prime to understand what changed. More test output is not necessarily better evidence; a short result linked to a clear requirement is easier to assess.

What should be agreed before a subcontract is signed?

Decide who supplies the environment and test data, who reviews each increment, how findings are classified, how changes are authorized, and what the receiving team must be able to operate. Address source access and software rights in the agreement rather than assuming a repository invitation resolves them.

Our teaming agreement and subcontract guide explains those commercial boundaries. If you are still choosing the delivery team, use the software subcontractor evaluation scorecard first.

Rainier's software subcontracting service covers application, API and integration scopes with an explicit handover. Share the workflow, dependencies and acceptance constraints so we can assess whether the scope fits.

Discuss a software work package→