What should count as acceptance for a custom software build?
Format: Article.
Accept the build when it does the work you agreed to buy and your team can check the proof. A smooth demo is useful. It does not show that every part of your scope works for the people who will use it. Write down what must pass before the final review.
Start with the workflow you have already chosen. Take a feature such as “review queue” and say what a person must be able to do with it. The buyer and builder should be able to run the same test and agree on the result.
Replace feature names with testable statements
“Has a dashboard” says little about acceptance. “An authorized service lead can find an unassigned request and assign it without changing the customer's account record” names a person, an action and a boundary. It can be tested.
For each statement, identify the input, expected output and evidence. Include what should not happen. A record that cannot be loaded must not display as an empty queue. A reviewer without approval rights must not gain them because a button is visible.
NIST's Secure Software Development Framework gives buyers and suppliers shared terms for secure software development.[3] It does not replace your agreed tests. The table below is our buying tool, not a NIST test schedule. Citing the framework does not certify the build or prove that it passes a test.
Copy this acceptance table
Give each row a stable test ID. Replace the examples with the purchased workflow, then have the business owner and delivery owner agree on the expected result.
| Test input | Expected output | Failure behavior | Human review | Evidence |
|---|---|---|---|---|
| Valid unassigned request | One request shown with correct source ID | Missing required fields hold the row | Lead checks assignment | Source record, saved result and test ID |
| Request already assigned | Existing owner remains visible | No silent reassignment | Lead resolves disagreement | Before and after owner values |
| User outside the allowed team | No access to protected record | Clear denied state | Access owner handles request | Allowed and denied test results |
| Source unavailable | Dated prior view or unavailable state | No false empty list | Lead follows agreed pause rule | Error state and last good read |
| Save response lost | No unsupported success message | Result marked uncertain until checked | Operator checks saved state | Request reference and readback |
Screenshots show what a screen looks like. They do not prove that a save lasts after sign-out. Nor do they prove the server blocks a user who lacks access. Ask to see those tests. Use approved test records in place of private customer data where possible.
A hypothetical signoff review
An established service company commissions a tool to route internal followups. The agreement says a team lead can assign a request, and another authorized user can then see the saved owner. The team supplies fictional requests for testing.
During review, the first user sees the new owner on screen. After a fresh sign-in, the second user still sees “unassigned.” The agreed test has failed, even though the first screen looked right. The builder needs to find the cause. Do not waive the test just because the screen design is done.
A different request arrives during the same meeting: automatically assign work based on each person's calendar. That was not part of the accepted scope. Record it separately. Do not let the new idea obscure the failed save, and do not assume it is included in the original price.
This distinction keeps the review fair. The builder gets a clear target. The buyer gets a usable outcome rather than a growing wish list or an ambiguous completion label.
Define what blocks release
Agree on which failures block the intended rollout. A wrong record update, cross-team data exposure or missing approval check may be a blocker. A cosmetic issue may be acceptable for a limited release if the owner records that choice. The severity depends on the actual use.
If you accept the build with a limit, write down who it affects and what they must avoid. Name who will fix it and when you will check again. Keep untested work out of the pass list. “Not tested: no provider access” is honest and gives the next reviewer a clear task.
Retest failures on the corrected build. Keep its version and environment with the result. Evidence from yesterday's candidate should not be used to accept a different package without checking what changed.
Record who accepts what
The final packet should show the agreed scope, test results, open items and authorized decision maker. Separate acceptance of the software from permission to connect production data, send messages or change access. Those actions may need their own approval.
Bring one test row and a hard case to Core Agentic. Book a Demo to discuss a custom design for your team's work. Ask what proof would show a successful save, a failed save and a request held for review.
Sources
These sources describe the named provider or framework. They do not establish a Core Agentic integration, customer result or certification.