Software Development Deliverables: Milestones & Acceptance

Every serious engagement produces artifacts, and software development deliverables are the evidence that the contract is being honored. This guide is the catalog version: what lands in your inbox at each milestone, who signs off, what acceptance looks like, and how each artifact ties to a payment trigger or a handover clause.

Written for the product leader, PMO, finance operator, and procurement lead tracking a six- or seven-figure build without writing code. Companion references: the software development lifecycle, the mobile app development process, and requirements engineering. This post takes the reverse view: artifacts first.

Why deliverables matter more than status reports

A status meeting reports what people felt they accomplished. A deliverable is a file you can open, a URL you can log into, or a repo you can clone. The difference matters on four fronts.

• They define "done". Without artifacts tied to acceptance criteria, every end-of-sprint debate becomes opinion vs. opinion.
• They anchor milestone payments. Fixed-bid and milestone-triggered contracts release funds against artifacts, not dates. A signed wireframe pack unlocks the design invoice; a staging deploy with passing UAT unlocks the release tranche.
• They survive team turnover. If the vendor's lead developer leaves mid-project, the demo video, OpenAPI spec, and test report still exist.
• They form contract-level acceptance evidence. In a dispute, the written record is what counts. Signed acceptance on a specific artifact beats Slack threads every time.

Insist on a deliverables schedule attached as an appendix to the MSA. Treat it as load-bearing.

The deliverables catalog

The table below covers the full set of software project deliverables a serious engagement should produce. Waterfall, Agile, and hybrid shops produce the same artifact types; only cadence differs.

Use this as a starting template. Strip rows that do not apply (a small internal tool does not need a full threat model). Do not strip SBOM, runbook, or API documentation. Those three matter most when something breaks at 2 a.m.

Acceptance criteria 101

Acceptance criteria translate intent into verifiable behavior and are the single most load-bearing technique for controlling software development deliverables quality. Three patterns do most of the work.

Given / When / Then

The Gherkin-style pattern forces precision about preconditions, action, and expected outcome. A concrete user story example, drawn from a fintech transfer feature:

User story: As an authenticated account holder, I want to send a domestic USD transfer to a saved beneficiary so I can pay my landlord without re-entering bank details.
AC 1 — Given I am signed in and the beneficiary is saved, When I submit a transfer with a valid amount under my daily limit, Then the transfer is queued within 2 seconds and I receive a confirmation number.
AC 2 — Given my available balance is below the amount, When I submit the transfer, Then the UI displays an "insufficient funds" error and no transaction is queued.
AC 3 — Given the beneficiary account is flagged, When I submit the transfer, Then the request is held for compliance review and I receive a notification within 5 minutes.

Each AC is testable and unambiguous. QA writes one test case per AC; the product owner signs off on each.

Non-functional acceptance criteria

NFRs need their own acceptance language because they cannot be expressed as user stories. A concrete example for the same fintech feature:

NFR — Performance: The transfer submission endpoint responds in under 400 ms at the 95th percentile under a sustained load of 200 requests per second, measured in a dedicated load-test environment for 15 continuous minutes.
NFR — Availability: The transfers service maintains 99.9% monthly availability, measured by synthetic checks every 60 seconds against the health endpoint.
NFR — Security: All transfer requests are authenticated with OAuth 2.1 access tokens, logged immutably for 7 years, and the service passes a PCI-DSS scoping review before general availability.

Definition of Ready and Definition of Done

DoR is the checklist a story must pass before the team picks it up: user role, business value, AC, mockups, dependencies, estimate. DoD is the checklist an increment must pass before it is shippable: merged to main, peer-reviewed, unit and integration tests green, staging deploy successful, telemetry in place, docs updated, AC demo accepted. Document both, post in the wiki, and enforce in sprint planning and review.

What to reject in a review

When a milestone handoff arrives, run it through this checklist before signing. Rejecting here is cheap; rejecting after production is not.

• Missing tests. No unit coverage on new business logic, no integration tests for new endpoints, no critical-path E2E tests.
• Undocumented endpoints. A new API exists but is not in the OpenAPI spec or the Postman collection.
• No rollback plan. The release notes describe a forward path but not how to revert within 10 minutes if something breaks.
• No runbook. The feature is in production but the on-call engineer has no written steps to diagnose common failure modes.
• No observability. The new code ships without logs, metrics, or traces. If a user complains, you cannot investigate.
• No accessibility audit. Screens go live without a WCAG 2.2 AA check, which is both an ethics issue and, in many US contexts, an ADA-litigation risk.
• Hard-coded secrets. Keys, tokens, or credentials in the repository rather than in a secrets manager. A grep for common patterns (AWS keys, JWT secrets) is a 30-second audit.
• No SBOM on handover. You cannot evaluate license risk, supply-chain risk, or vulnerability exposure without a software bill of materials. This is the single deliverable most often skipped and most often regretted.

Payment milestone patterns

How software development milestones map to invoices determines your cash-flow exposure. Three patterns dominate US engagements with nearshore partners.

20 / 30 / 30 / 20 fixed-bid

Common in fixed-scope builds: 20% on signing and discovery, 30% on design and architecture sign-off, 30% on feature-complete and UAT, 20% on release and handover. Predictable for CFOs; painful if scope drifts, because change orders sit outside the baseline.

Milestone-triggered T&M

Vendor bills weekly or monthly against hours worked, but payment gates require milestone artifacts — monthly invoices release only after sprint-demo sign-off, updated backlog, and deployed staging build. Combines T&M flexibility with fixed-bid discipline.

Retainer plus milestones

A monthly retainer covers a dedicated cross-functional team; quarterly milestones release bonus tranches tied to big artifacts (major release, compliance certification, migration complete). Suits ongoing product teams rather than one-shot builds.

Match the pattern to the work. Do not apply 20/30/30/20 to an open-ended product team; do not put a fixed-scope MVP on a pure retainer. Our ten questions to ask before hiring a software vendor covers the procurement side in depth.

Agile vs. Waterfall: same artifacts, different cadence

Agile projects do not produce fewer deliverables than Waterfall projects — they produce the same artifact types, in smaller batches, more often. A Waterfall build ships one 120-page SRS, one monolithic design system, one release candidate, one UAT cycle. An Agile build produces a lean PRD plus a continuously refined backlog, design tokens evolving sprint over sprint, a staging deploy every two weeks, and UAT pockets tied to feature flags. The total volume of agile deliverables equals or exceeds Waterfall; only timing differs.

When evaluating vendors, "we are Agile, so we do not write docs" is a red flag. Agile shifts when and how documentation is produced; it does not abolish it.

The escape-velocity handover kit

The handover kit is the set of artifacts that let you take the product to a different vendor, bring it in-house, or keep it running if the original team disappears. If any item below is missing, you have vendor lock-in regardless of contract language.

• Source code repo. Transferred to a client-owned GitHub/GitLab/Bitbucket org with full commit history. Client is owner; vendor keeps read access during warranty only.
• CI/CD pipelines. Pipelines live in the repo (GitHub Actions, GitLab CI), documented, executable by the client's DevOps engineer on day one.
• Infrastructure as code. Terraform, Pulumi, or CloudFormation describing production and staging. No clickops resources only the vendor knows about.
• Credentials transfer. Root account ownership transferred, secrets rotated, signed attestation of rotation.
• SBOM and license inventory. Current CycloneDX or SPDX SBOM plus a spreadsheet mapping every third-party library to license and version.
• API and integration docs. OpenAPI specs, Postman collections, integration credentials transfer plan, webhook signing keys.
• Runbooks and SOPs. Incident response, data requests, backup and restore, rollback, on-call escalation.
• Observability assets. Dashboards, alert definitions, log retention policies, synthetic checks in client accounts.
• UAT sign-off log. Evidence of what was tested, what passed, what was deferred with agreed compensating controls.
• Knowledge transfer sessions. At least two recorded sessions — architectural and operational — with the client's future maintainers.

Ask for this checklist in writing before the first invoice is paid. If a vendor hesitates, that is the answer.

How FWC structures deliverables per engagement

At FWC, the default delivery rhythm is public so clients can plan around it: every engagement ships a deployable increment to a client-accessible staging environment at the end of every sprint, on a two-week cadence. A recorded demo goes out the same day with updated release notes and backlog, so a product owner in Austin or Boston can replay without joining the live call.

Architecture decisions are captured in lightweight ADRs in the repo, the API contract is kept in OpenAPI and reviewed at every integration point, and the test pyramid is built from day one rather than retrofitted at UAT. The handover kit above is the closing deliverable of every engagement regardless of contract type; clients own their code, cloud accounts, and secrets before the final invoice clears. That rhythm is why we work as a nearshore partner for US companies on a one-to-three-hour timezone overlap without a coordination tax. Our custom software development guide and nearshore outsourcing guide cover the commercial context.

Bringing the deliverables discipline into your next build

Strong software development deliverables discipline is what separates a project you can audit, defend, and transfer from one you are hostage to. Insist on a deliverables appendix to the MSA. Tie each payment milestone to specific artifacts with explicit acceptance criteria. Run the rejection checklist at every review. Demand the full handover kit before the final invoice. None of this is adversarial; it is how mature buyers and mature vendors both protect their investment.

Talk to FWC about your next engagement

If you are scoping a custom software or mobile build and want a partner who runs this kind of delivery cadence by default, request a project estimate or get in touch with our team. We will walk you through the milestone schedule, acceptance criteria patterns, and handover kit contents on a 30-minute call before any commitment.