Build or buy AI automation: decide around the workflow

Define the requirements that change the decision

List the workflow's essential outcomes and the constraints that cannot be compromised. Examples include a specific approval sequence, access restrictions, supported languages, response time or a required accounting integration. Keep attractive extras separate so they do not overwhelm the comparison.

Test whether the business process itself needs simplification. Reproducing an unnecessary manual step in custom software can make it harder to change later. At the same time, do not discard a necessary control merely because a standard product does not support it conveniently.

Compare three delivery routes

A ready-made product may offer a quick starting point and established support, but its behaviour and integration boundaries are controlled by the vendor. A configurable platform can adapt forms and workflows while retaining vendor dependencies. A custom application offers more control over the experience and logic, with additional engineering and maintenance responsibilities.

Use one representative scenario to compare all three routes. For example, process an enquiry that refers to an existing customer, contains an attachment and requires manager approval. Evaluate the complete path, including failed lookups and corrections, rather than comparing isolated model answers.

• Ask each option to demonstrate the same exception cases.
• Verify export and API access before assuming integration is possible.
• Separate current features from roadmap promises.

Evaluate quality, data controls and operating cost

Run the candidate options against an agreed evaluation set. Assess the result, the evidence shown and the effort needed to correct it. OpenAI's model-selection guidance illustrates the broader tradeoff between quality, speed and cost; the application around the model adds its own integration and review costs.

Compare licences, development, implementation, monitoring, training and ongoing changes over a realistic planning period. Check provider terms for your data and connected services. A low initial subscription can be poor value if staff must manually reconcile results, while custom development may be excessive for a straightforward supported workflow.

Make ownership and exit part of the purchase

Identify who owns prompts, workflows, data mappings and operational documentation. Agree who responds when an integration fails and how a provider change reaches your team. For custom work, define source-code access, deployment responsibilities and the skills needed to maintain it.

Test whether important records and configuration can be exported in a usable form. Decide how work returns to a manual or alternative process if the service is withdrawn. NIST's voluntary AI framework provides a useful reminder that operating responsibilities continue after the initial decision; buying a product does not remove them.