Buyer's guide / development partners
Choose the team whose work you can verify and take over.
A development company should be able to explain what it will build, demonstrate how it tests difficult cases, and show what your team will control when the engagement ends. Turn those expectations into evidence requests before comparing proposals.
The selection principle
Compare evidence against the job you need done.
Define the workflow, users, data boundary, integration points, and acceptance conditions first. Ask each shortlisted company to respond to the same brief with named responsibilities, inspectable artifacts, assumptions, and unresolved questions. Evaluate mandatory requirements before weighing delivery approach, collaboration, and commercial fit.
- Proof of experience
- A reference or sample can show how a team approached earlier work. Establish what the proposed team actually delivered, what others supplied, and which constraints resemble yours. Past work does not establish the result of your project.
- Proof of a proposed design
- A walkthrough can expose interfaces, data flows, failure paths, and maintenance assumptions. It remains a proposal until tested. Ask what evidence would cause the team to change its design.
- Proof of your acceptance
- Use agreed cases, permitted data, and observable outcomes from your workflow. A vendor benchmark or polished demonstration cannot replace the buyer's own acceptance criteria.
Four diligence reviews
Ask to see the work behind the answer.
Use these reviews to structure a technical discussion with the people proposed for delivery. Request redacted examples or controlled demonstrations where confidentiality prevents sharing. Do not ask a supplier to expose another customer's code, records, or secrets as proof of competence.
Engineering and delivery
01Buyer question: Can this team build and maintain the whole workflow?
- Evidence request
- A relevant architecture example, a redacted change review, test evidence, and the proposed team's responsibilities.
- Buyer preparation
- Your current systems, user journey, constraints, integration owners, and known exceptions.
- Review exercise
- Ask an engineer to trace one request from input validation through storage and downstream systems, then explain an interrupted or rejected path.
- Decision owner
- Your technical lead assesses architecture and maintainability; the product owner confirms workflow fit.
- Useful result
- Clear boundaries, ordinary-software alternatives, realistic dependencies, and an explanation of how defects are found and repaired.
- Reason to pause
- The proposal jumps from a model response to a production outcome without accounting for integration, state, or recovery.
- Selection record
- Named delivery roles, assumptions, dependencies, review access, and milestone artifacts.
Data and security
02Buyer question: Where will our information and authority go?
- Evidence request
- A data-flow map, dependency list, access model, retention approach, and relevant security test evidence.
- Buyer preparation
- Data classifications, permitted uses, existing access rules, and the person authorized to approve new processing.
- Review exercise
- Trace a representative record through model, hosting, logging, support, and backup paths. Ask how an unauthorized user and hostile source content are handled.
- Decision owner
- Security and data owners assess the proposed boundary and remaining exposure.
- Useful result
- Specific answers about each component and operator, with gaps recorded and assigned.
- Reason to pause
- A provider's certification is presented as proof of the entire custom application's security.
- Selection record
- A reviewed processing and dependency map with conditions for access, change, and incident handling.
Evaluation and acceptance
03Buyer question: How will we know whether the system is useful enough for its intended scope?
- Evidence request
- An evaluation plan, representative test cases, failure analysis, and a sample acceptance report.
- Buyer preparation
- Current baseline, task variants, costly errors, reviewer roles, and expected blocked outcomes.
- Review exercise
- Give the team an ordinary case, an ambiguous case, and a case it should refuse or escalate. Inspect source support, system effects, and the reviewer's actual work.
- Decision owner
- The workflow owner defines usefulness; qualified reviewers assess consequential outputs.
- Useful result
- Separate results for quality, boundary compliance, human corrections, response time, and resource use, with tested limits stated.
- Reason to pause
- One accuracy percentage appears without a dataset, scoring rule, failure breakdown, or explanation of excluded cases.
- Selection record
- An acceptance protocol specifying evidence, responsibilities, and what happens when criteria are not met.
Ownership and continued operation
04Buyer question: Can another capable team operate and change what we receive?
- Evidence request
- A deliverables inventory, dependency and licence record, deployment instructions, operating guide, and proposed transition responsibilities.
- Buyer preparation
- Your intended hosting and account ownership, internal skills, support expectations, and likely exit scenarios.
- Review exercise
- Ask how a new maintainer would deploy a known version, run its tests, locate unresolved work, rotate access, and export required records.
- Decision owner
- Technical and operating owners test usability; commercial and legal reviewers resolve rights and agreement terms.
- Useful result
- A concrete handover path that distinguishes custom assets, supplier assets, third-party services, and data.
- Reason to pause
- Source-code delivery is described as complete ownership while critical accounts, licences, configuration, or evaluation data remain unexplained.
- Selection record
- An agreed asset and responsibility schedule, transition test, and list of continuing dependencies.
Claims into acceptance
Make the next question specific enough to answer.
The examples below are hypothetical supplier statements. They are not allegations about a company. Use each one to distinguish what a document can establish from what needs a controlled test in your environment.
| Supplier statement | Ask to inspect | Test locally | Buyer retains | Unresolved if |
|---|---|---|---|---|
| We have done this before | Relevant scope, the proposed team's contribution, and a permitted reference or redacted example. | A walkthrough of the important differences in your workflow. | Judgment of relevance and reference verification. | No connection can be established between past work and the proposed delivery team. |
| The answers are accurate | Dataset, scoring method, model version, and error breakdown. | Representative cases including missing, conflicting, and unsupported evidence. | Definition of acceptable errors and required review. | A benchmark replaces workflow-specific acceptance. |
| Your data stays private | Component-level processing, access, retention, and support paths. | Denied-access tests and inspection of actual logs and configuration. | Approval of the data boundary and unresolved risk. | An important processor or support access path is unknown. |
| It integrates with your systems | API assumptions, permission scopes, version support, and error contracts. | A controlled end-to-end path with timeout and duplicate-request cases. | System access and release authority. | Only a mocked connector has been demonstrated. |
| You own the result | Asset inventory and the proposed rights, licences, accounts, and delivery format. | An independent maintainer can build, test, and operate the agreed deliverable. | Commercial and legal agreement on rights and restrictions. | An essential dependency cannot be transferred or used under the intended arrangement. |
| We will support it | Support scope, named responsibilities, escalation, change, and transition arrangements. | An incident and handover rehearsal using the proposed runbook. | Service priorities, risk acceptance, and exit decisions. | Coverage, exclusions, or the handling of upstream model changes remains ambiguous. |
A comparable selection process
Use the same decision basis for every candidate.
This is a practical commercial evaluation sequence, not a substitute for applicable procurement rules. Keep the effort proportionate to the intended system and give candidates a clear way to disclose uncertainty.
- 01
Write the common brief
Describe the workflow, baseline, constraints, permitted information, expected deliverables, and decision owners. Separate essential requirements from preferences.
- 02
Review written evidence
Request the same artifact list and assumption table from each candidate. Record unsupported answers as unresolved rather than awarding confidence for presentation quality.
- 03
Meet the delivery team
Walk through difficult cases with the people expected to do the work. Establish subcontracting, continuity, escalation, and how changes in team composition would be handled.
- 04
Test a bounded slice
Where justified, agree a small evaluation engagement with permitted data, deliverables, cost boundaries, and stop criteria. Use the same acceptance protocol across comparable trials.
- 05
Record the decision
Resolve essential gaps before selection. Compare remaining strengths and total operating assumptions, then record the reason, accepted limits, agreement conditions, and next evidence gate.
Keep the comparison honest
A weighted score should not hide a missing requirement.
Before reviewing proposals, classify each criterion as mandatory, comparative, or informational. The classification and its owner belong in the selection record.
- Separate gates from preferences
- If your required data boundary cannot be met, a better interface demo does not compensate. Mark the candidate ineligible for that scope or revise the requirement through its accountable owner, with the reason recorded.
- Record evidence strength
- Distinguish a supplier statement, a document inspected, a reference checked, and a locally observed test. Keep evidence dates and scope beside the rating so an old or unrelated artifact cannot silently stand in for current proof.
- Compare complete cost assumptions
- Ask what is included and excluded across discovery, data preparation, integration, evaluation, review effort, hosting, model usage, support, change, and transition. Compare scenarios and assumptions; do not treat an unbounded usage estimate as a fixed operating cost.
- Apply the method to Werkon too
- This guide is published by a development provider. Ask us for the same evidence, discuss gaps, and compare alternatives. The guide does not imply that Werkon has passed your acceptance process or holds credentials that have not been evidenced.
Before the final shortlist
Questions that change the decision.
A useful answer should narrow uncertainty or identify the next piece of evidence.
- How much industry experience is enough?
- There is no universal threshold. Ask which workflow constraints the experience helps the team understand, who will supply domain judgment, and how unfamiliar cases will be tested. A familiar industry logo does not establish knowledge of your specific process.
- Should we reject a company without a matching public case study?
- A confidentiality restriction can be legitimate. Look for permitted alternatives such as a redacted design, reference conversation, or controlled technical exercise. If the relevant capability remains unverified, record that gap rather than treating either the absence or the explanation as conclusive.
- What should a trial prove?
- It should resolve a material uncertainty: source quality, integration feasibility, boundary enforcement, review effort, or maintainability. State what would count as failure and what artifacts remain useful if you stop. A trial need not pretend to be a complete production system.
- Do certifications and benchmarks settle the security question?
- No. Inspect their issuer, scope, date, exclusions, and relevance, then review the proposed system. Security also depends on configuration, custom code, access, dependencies, operation, and how the team handles changes and incidents.
- What does a useful handover demonstration look like?
- A capable maintainer who did not build the system follows the supplied instructions, runs tests, deploys a known version in an agreed environment, and handles a representative failure. Record missing knowledge and dependencies before accepting the handover milestone.
Source basis
Sources behind the control model.
- 01
UK Government
Guidelines for AI procurementThe 2020 public-sector guidance informs problem definition, supplier evidence, and lifecycle planning. It is not presented as current procurement law or a mandatory process for private buyers.
- 02
NIST
AI Risk Management FrameworkVoluntary risk-management context for intended use and evaluation. The live page states that AI RMF 1.0 is being revised; framework alignment does not establish supplier performance.
- 03
NIST
SP 800-218A: Secure Software Development Practices for Generative AIAI-specific secure-development profile used with the SSDF. It provides diligence topics, not a certification of a development company or application.
- 04
UK National Cyber Security Centre
Mapping your supply chainSupports understanding suppliers and dependencies beyond the company named in a proposal.
- 05
UK National Cyber Security Centre
Guidelines for secure AI system developmentFrames security work across design, development, deployment, operation, and maintenance. Actual implementation evidence remains necessary.
- 06
W3C Web Accessibility Initiative
Evaluating Web Accessibility OverviewSupports including accessibility evaluation in acceptance. Automated checks alone cannot determine whether an interface is accessible.
Start with one real workflow
A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.
Show Us the WorkflowStart with the free automation readiness checklistOBSERVEQUANTIFYDECIDEBUILD