The short answer#
Buy when a product meets your workflow and control requirements without extensive adaptation. Build the parts that distinguish your business when your team can operate them; bring in a delivery partner when custom work is needed but capacity or experience is missing. Compare the options against the same acceptance tests, operating costs and exit requirements before committing.
Decide which part of the workflow you need to own#
The decision is about who will deliver and maintain a business capability. Start with the work: who uses it, what a successful result looks like, which information it may access and what happens when it is wrong.
For this decision, use three working definitions:
- Buy: adopt a product and configure it around an existing workflow.
- Build: have your own engineers develop and maintain the application or its custom components. This can use an existing model; training a model is a separate decision.
- Partner: commission a delivery firm to configure a product, build custom components or do both, with an explicit support or handover arrangement.
A partner can help you buy or build. It is a choice about delivery responsibility alongside your choice of technology. Write down both: what you will adopt, and who will implement, operate and change it.
Our suggested starting position is to test a product against the essential requirements first. Fund custom work only for a consequential gap: a workflow, permission rule, integration or business capability that the product cannot adequately support. A preference for your own interface is a weaker reason than a permission boundary you cannot enforce.
Remove options that fail essential requirements#
A low price cannot compensate for an option that exposes restricted information or cannot complete the task. Agree the rejection conditions before comparing proposals.
For a document assistant, that might mean a user must never receive content from a restricted department, answers must point to an approved source, and unsupported questions must go to a person. State the expected behaviour in testable terms. Have the business owner set the acceptable answer quality and the security owner approve access and data handling.
The UK ICO's AI procurement toolkit recommends deciding acceptable accuracy before procurement and verifying it through due diligence. Use that discipline to set the trial's acceptance criteria.
Ask each candidate to demonstrate the same difficult cases, with authorised representative data. Include missing information, conflicting documents, revoked access and attempted instructions hidden inside a document. An unsupported claim in a proposal remains an open requirement. If no option passes, narrow the use case or resolve the missing control before funding deployment.
Compare delivery choices after that first test#
Use this table as a decision aid, then replace each assumption with evidence from your trial.
| Choice | Prefer it when | What you still need internally | Evidence before commitment |
|---|---|---|---|
| Buy | The product fits the workflow and its controls pass your tests with manageable configuration | A business owner, administration, data ownership and someone who can challenge the supplier | Your cases working in the product; documented limits, permissions, usage charges and export options |
| Build | A valuable requirement needs custom behaviour and your engineers can sustain it | Engineering capacity for integration, testing, security, releases and support | A working version of the difficult custom part, an operating plan and capacity allocated after launch |
| Partner | Custom delivery is justified but your team lacks the capacity or relevant experience | Someone authorised to accept the work, control access and own the supplier relationship | Delivery milestones tied to tests, named responsibilities, support terms and a demonstrated handover or ongoing service arrangement |
With a product that already fits, your path to first use is configuration and validation; an internal build also needs design, implementation and a release, while a partner adds supplier selection and onboarding but can supply missing delivery capacity. Ask each team for the earliest usable milestone and its dependencies. A wrong choice leaves the business paying for workarounds around a product, a custom system nobody can maintain or continuing partner dependence without a usable handover.
Buy does not remove implementation work. Put configuration, information clean-up, access mapping and user adoption into the plan rather than assuming the licence covers them. Reject the buying option if essential adaptations leave you maintaining an unsupported second application around it.
Build needs a reason that survives the prototype. Before assigning engineers, ask what will happen when documents change, a model is replaced or the person who wrote the integration leaves. If that work has no owner or budget, the build proposal is incomplete.
Partner needs a delivery contract you can assess. A fixed deliverable should name the workflow and acceptance evidence. If the partner will operate the service, specify what you can inspect and how changes and incidents will be handled. If your team will take over, require it to make and deploy a change before accepting the handover.
The capability to assess suppliers deserves its own place in the plan. In its April 2026 review of US federal AI acquisitions, GAO reported agency officials' difficulties obtaining technical expertise to evaluate proposals and understanding AI costs. Reserve internal review capacity whichever route you choose.
The delivery arrangement can change; your acceptance criteria and accountable business owner must carry through all three options.
One workflow, three different decisions#
Consider a hypothetical internal procedure assistant for a manufacturer. It helps staff find approved instructions and drafts an answer for review. This is an illustration, not a client example or a promised outcome.
First, suppose an existing product handles the document formats, applies the required access rules and passes the agreed answer tests. Staff can use it within their current process. Buying is the leading option: there is no demonstrated need for a custom application. Confirm the ongoing administration and review workload before signing.
Now change one requirement. Every answer must retrieve the current machine configuration from a legacy system and select the procedure for that exact configuration. Suppose the product trial cannot support that check. The team should test this integration before committing to a full build. A custom component becomes worth considering because the gap affects whether the instruction is appropriate, rather than simply how it looks.
Finally, suppose that custom component is necessary, but the internal engineers cannot support the work alongside their existing commitments. A partner becomes a candidate to deliver it. Keep an internal owner, give the partner limited access, and agree whether operation stays with the partner or transfers to your team. If neither side can support it afterwards, defer deployment.
The lesson is to change the delivery decision when the requirement or your capacity changes. Do not defend an early choice after the evidence has moved.
Compare cost over the same operating period#
Ask for a cost worksheet covering setup and your organisation's normal planning period. Use the same workload assumptions for each option: users, completed tasks, document updates, peak demand and human review effort. Keep quoted amounts separate from estimates.
| Cost to account for | Buy | Build | Partner |
|---|---|---|---|
| Getting into use | Configuration, integration and adoption | Engineering, infrastructure and deployment | Discovery, delivery and your team's review time |
| Keeping it useful | Licence or usage charges, administration and output review | Model or hosting charges, maintenance, evaluation and output review | Platform charges, support fees, retained internal ownership and output review |
| Changing or leaving | Export, migration and replacement configuration | Replacement components, migration and engineer time | Contract exit, knowledge transfer, migration and any continuing third-party licences |
For each cost category, ask what is included and what depends on usage or change requests.
Compare the total with the number of completed tasks the business accepts, including the time people spend correcting or rejecting outputs. A licence comparison alone will not tell you whether either option improves the workflow. The Gen AI cost worksheet develops that calculation further.
Keep exit requirements concrete. Ask which source documents, configurations, evaluation cases, logs and custom code you can retrieve and reuse, in what format, under which rights and at what charge. Request a sample export during the trial. Possession of an export does not by itself show that a replacement system can use it.
What this means for you: fund a decision, then a deployment#
For the next approval meeting, request a bounded trial with a fixed scope and spending limit. Its output should be a decision record, with these items completed:
- A workflow and owner: the task, intended users, current baseline and person accountable for accepting the result.
- Acceptance evidence: representative cases, expected behaviour, quality thresholds and failures that rule out deployment, agreed before the trial.
- A comparison: results for the viable delivery options, unresolved requirements and costs under the same workload assumptions.
- An operating arrangement: who maintains data, authorises changes, monitors quality and responds when the service fails.
- A recommendation: proceed, narrow the scope or stop, with the evidence and conditions that would change the decision.
Use the trial to choose a route, then apply the five production gates to the chosen solution before deployment.
For purchased or partner-delivered components, ask for contractual rights to inspect the relevant evaluation evidence and agree how oversight continues. NIST's July 2024 Gen AI profile, a voluntary risk-management resource, recommends contractual evaluation rights for third-party processes and monitoring of third-party systems after deployment. Treat signing the contract as the start of that relationship.
Questions to ask before choosing build, buy or partner#
- Which essential requirement rules out each option, and where is the test result?
- Which custom work is necessary for the business outcome, and which could we remove?
- Who has the capacity and authority to accept, operate and change the system after launch?
- What is the cost per accepted task once review and rework are included?
- What can we retrieve and reuse if the product, platform or delivery firm changes?
- What evidence would make us stop rather than extend the trial?
If the choice is stalled, bring one workflow, its constraints and the team capacity you actually have. A consulting engagement can focus on the architecture and production-readiness questions that decide the route. Discuss your project.