before you buy.
ask for evidence.

start with one acceptance record

Use this practical discussion template for the most important workflow before expanding the scope. Replace the example with your own situation, keeping confidential customer data out of an initial enquiry.

Outcome

What should a named user be able to do?

Example

What input and expected result would demonstrate it?

Evidence

Which test, demonstration or inspection will check the agreed version?

Owner

Who accepts the result, and who handles a failure after launch?

Open question

What is still unknown, and when must it be resolved?

open the acceptance worksheet (.txt) — an editable copy with space for evidence, owners, open questions and decision dates. Save or copy the text to use it. No sign-up.

An illustrative criterion: an operations coordinator must export every approved order exactly once. Check a known dataset with pending, approved and duplicate records; preserve the output and tested version.

1. establish whether a build is justified

Ask: what existing product, integration or process change was considered, and why would it be insufficient? Identify the people who will use the system and the decision or task it improves. Separate essential behaviour from possibilities for later.

Ask to see: a short scope with exclusions, dependencies and unresolved assumptions. Request a representative workflow, including an exception. “Automate the process” leaves room for different interpretations; a shared example makes those differences visible before work begins.

A small pilot can resolve an uncertain integration or business rule. Its purpose, cost and stopping point should be clear. If you are still choosing an approach, use the build, buy or automate decision tool to identify the next question to resolve and keep a short starting brief.

2. agree what passing means

Ask: who decides that the software works, using which examples? What happens when a test fails or the parties disagree? If AI is involved, distinguish generated suggestions from actions that change real records.

Ask to see: expected outputs, realistic failure cases, the checked version and a list of remaining limitations. Include permissions, unavailable dependencies and incorrect input. A happy-path demo is useful, but it leaves unanswered how the system behaves when ordinary work goes wrong.

Do not substitute a generic “all tests passed” statement for the outcome you need. Equally, avoid asking for an elaborate test programme without reference to risk. The evidence should match the consequences of failure in this particular workflow.

3. clarify source, accounts and access

Ask: what will you receive, what can you change, and what depends on a continuing subscription or the supplier's account? Discuss source code, third-party components, hosting, domain control, administrative access and data export separately. “You own it” is too vague to answer all of them.

Ask to see: a handover inventory naming the account owner, access arrangement, recurring supplier and exit step for each important dependency. Identify how credentials will be transferred securely and how old access will be removed. An exported code folder alone may not be enough to operate the system.

For a common vocabulary when discussing secure development with a supplier, consult NIST's Secure Software Development Framework. A reference to the framework does not establish that a supplier follows it; request evidence relevant to your project.

4. rehearse a change and a recovery

Ask: who approves a release, how is it checked before users depend on it, and who can restore service? Determine how a failed update affects stored data. Reverting application code and recovering data are different operations.

Ask to see: a release record, backup arrangements and a demonstrated recovery appropriate to the system. Where a data change cannot simply be undone, ask what repair path and decision owner replace a straightforward rollback. Record the limits instead of assuming every release is reversible.

Also distinguish a defect in agreed behaviour from a new requirement. A change process should explain how additional work affects scope and price before that work is undertaken.

5. price the operating life

Ask: which costs are included in the build, and which continue afterwards? Consider hosting, database storage, external APIs, model usage, monitoring, licences, support and the work your own team must do. Request the assumptions behind a monthly estimate and what happens if usage grows.

Ask to see: a cost breakdown and a support arrangement naming response expectations, coverage, exclusions and escalation. Do not infer ongoing maintenance from a development quote. If no continuing support is purchased, establish who will take responsibility instead.

For an ongoing delivery relationship, discuss both changes delivered and failures or rework. DORA's delivery metrics are a useful reference for that balance, applied to the system's context rather than as a competition between suppliers.

turn unanswered questions into the next step

Mark each item as evidenced, agreed but not yet checked, or unresolved. Give unresolved items an owner and a decision date. A gap in critical access, acceptance or recovery deserves resolution before you depend on the software; it should not disappear inside an average score.

Bring the record to a supplier conversation. Software Facto offers a free assessment and project-specific pricing. Describe the workflow, the people involved and what you want to improve; the scope and responsibilities of any engagement must be agreed separately.