Choose the delivery route
Build vs buy AI: decide when an existing tool is enough
The build-versus-buy decision asks which route can meet your workflow’s requirements at a cost you can support. Compare an existing product, configuration of your current systems and a custom build against the same job. Include exceptions, access and ongoing maintenance before choosing.
Test each route against the same job and exceptions, with ownership and maintenance included in the comparison.
Describe the job before choosing a product
Write the start, useful finish, information needed and human decisions. Identify the variation that makes the job difficult. Said’s reporting example shows why this matters: client-specific requirements can change both the route and the software needed to deliver it.
Mark requirements as essential or useful. “Show the current agreement and its source” is testable. “Use the best AI” is difficult to compare. Include requirements for the people using the system, such as an accessible review screen and a clear exception route.
The GOV.UK guidance on commercial products places understanding and testing the service before committing to technology. That government context is useful as a design principle; it is not a procurement rule for every private business.
Compare three realistic routes
| Route | Where it may fit | What still needs checking |
|---|---|---|
| Buy an existing product | The job closely matches an established product workflow. | Client access, exceptions, integrations, exports and support. |
| Configure existing systems | Your current tools can perform the steps with agreed rules. | Maintenance of configuration, approvals and reliable retries. |
| Build a custom layer | Important requirements or relationships do not fit the available routes. | Engineering ownership, testing, hosting, updates and handover. |
These routes can combine. You may buy infrastructure and build the part that encodes your firm’s method. Keep the business information and rules understandable so a supplier’s internal structure does not become the only record of how the service works.
Ask who will change the workflow when a client requirement changes. A product that is easy to start can still need considerable configuration. A custom build that nobody can maintain creates a different kind of dependency.
Test the options with the same examples
Use a normal job, a client variation and a missing-information case. Compare the accepted result, review effort and exception handling. Give each option the same approved inputs and expected outcome.
Inspect what is stored, what is sent to a model and what can be exported. Confirm these through current product documentation and a test in the configuration you would actually use. General supplier claims cannot establish your specific setup.
Include a change test: replace a source, change a requirement or disable an integration. That reveals how the system is supported after the initial demonstration.
Include the cost of ownership
Estimate setup, information preparation, integration, model usage, review, support and future changes. Assign a person or supplier to each ongoing task. A licence price and a development quote cover different parts of that total.
Record assumptions about volume and how often the job changes. Compare several plausible levels of use. A design that works for a small pilot may need different support when every client uses it.
Make a decision with evidence and gaps
Worked example
Choosing a reporting preparation route
Invented teaching example. No client outcome is claimed.
NEED
Prepare agreed reports for several invented client variations with checkable sources.
COMPARISON
Test whether an existing reporting tool can handle the source and review requirements.
Test configuration of current systems for the same jobs.
Estimate a custom layer only for requirements those routes cannot meet.
DECISION EVIDENCE
Acceptable reports, complete review effort, maintainable changes and exportable client requirements.
LIMIT
No named product is scored and no route is assumed to win before the tests.
Further reading
Written by Said Lopez, founder of LeverageAI and author of Lean AI. Our guides draw on the method in the book and our work with clients.