Build, buy or integrate: choosing software with AI in mind

Your business needs software to work differently. You could buy a product, build an application or connect the systems you already have. Each proposal looks sensible on its own, but comparing them is harder.

AI-assisted development adds another claim to assess: that bespoke software can now be delivered faster or for less money. It may change the effort involved in particular tasks. It does not remove the need to understand the work, test the result and look after it.

A useful decision starts with the business process and the responsibilities you are prepared to take on. Here is how to compare the options without relying on a generic price range or promised productivity percentage.

Start with the workflows that matter

Choose the important tasks your software must support. Follow them from the first input through to the final outcome, including approvals, exceptions and information passed to other systems.

Separate requirements that protect a real business need from familiar habits. A process may need to change because it is unusual and valuable. It may also be unusual because an old tool forced people into a workaround.

Ask staff to show you difficult examples. Can an order be amended after it reaches the warehouse? What happens when a record appears twice? Who corrects a failed synchronisation? Those questions make product demonstrations and development proposals easier to assess.

Compare buying, building and integrating

Buy when an existing product fits the work

A ready-made product deserves serious consideration when it supports your important workflows and the business can work within its constraints. Configuration and a change to working practices may be more sensible than maintaining a separate application.

Test the fit with your own examples. Check permissions, reporting, accessibility, data export and the integrations you would depend on. Establish which features are included in the proposed subscription and which need additional products or services.

The vendor operates its product, but your team still has responsibilities. Someone must manage users, configuration, data quality and the relationship with the supplier. Buying software does not remove implementation work.

Build when the unmet requirement justifies it

Bespoke development can make sense when an important workflow cannot be supported adequately by the available products, or when a specific customer experience is central to the service you provide.

Be clear about what the business needs to control. That might be the workflow, the integration with an existing application or the order in which features are developed. Owning code does not automatically give you a secure, reliable or easy-to-change system; those qualities depend on the design and the work that follows.

Assess who will maintain the application, how changes will be tested and what another team would need to take it over. Include access to source code, deployment accounts and useful documentation in the proposal.

Integrate when the gap is between systems

You may already have suitable software for individual parts of the business. The problem is that people are copying information between them or dealing with incomplete updates.

In that situation, a custom integration may preserve the useful parts of your existing setup. Check the systems' supported interfaces, data ownership and failure handling before assuming a connector will be straightforward.

For Talking Tables, we worked on a bespoke application connecting Shopify stores with the WinMan ERP system. We improved the existing integration in stages, focusing on problems affecting orders and product information. This is an example of combining established products with custom development. It is not evidence of an AI-generated cost saving.

Ask what AI changes in the proposed work

AI coding tools can suggest code, tests and changes for a developer to assess. For example, GitHub's guidance on Copilot inline suggestions describes those capabilities and says users should review and validate suggestions. It also describes limitations, including inaccurate code and incomplete understanding of wider architecture.

When a supplier says AI makes a proposal cheaper or quicker, ask which tasks are affected and what evidence supports the estimate for your project. A demonstration of fast code generation does not establish the time needed for integration, testing, migration or user acceptance.

Ask how generated changes are reviewed, how behaviour is checked and who is responsible for the result. If a supplier has measured productivity on comparable work, examine what was included in that measurement. Avoid applying one percentage to the entire project without understanding its scope.

Also separate AI-assisted development from putting AI into your product. Developers can use a coding assistant to build an ordinary business application. A feature that sends customer information to a model introduces additional questions about the information used, the quality of outputs and how mistakes are handled. These are different decisions.

Compare costs over a useful planning period

Use the same requirements and planning period for each option. Include expected usage and plausible changes, with uncertain assumptions clearly marked.

• Initial work: discovery, configuration or development, integration, migration, testing and training.
• Running costs: subscriptions, hosting, usage charges, monitoring and support.
• Internal effort: administration, manual workarounds, user support and checking or correcting outputs.
• Change costs: new workflows, additional users, dependency updates and changes in connected systems.
• Exit costs: extracting usable data, transferring accounts, replacing integrations and moving to another supplier.

Request estimates against those headings. A low subscription price can sit alongside substantial setup work; a development quote can omit ongoing responsibilities. Neither comparison is useful until the scope is clear.

Test the assumptions that could change the decision. If usage grows, which charges rise? If a key integration becomes unavailable, what would the fallback involve? If your original developer is no longer available, can another team maintain the application?

Use a small investigation to answer the expensive unknown

You do not always need a complete specification before making progress. Identify the uncertainty most likely to change the recommendation and choose a proportionate way to examine it.

That could be testing a product against a difficult workflow, checking whether an API exposes the information you need, or building a limited prototype of a bespoke interaction. Our rapid prototyping work can support that kind of focused investigation.

Define what the investigation should establish and what it will leave unanswered. A prototype can help assess an interaction; it does not prove that the finished service will be secure, accessible, maintainable or ready for production.

Record why the chosen option fits

A useful recommendation names the options considered, the requirements that matter, the assumptions behind the cost comparison and the responsibilities the business will retain. It should explain why an alternative was rejected and what change in circumstances would justify revisiting the choice.

For a buying decision, that might mean accepting a product's limitation because the workaround is small and understood. For a bespoke build, it might mean accepting ongoing maintenance in order to support an important workflow. For an integration, it might mean keeping two existing products while assigning clear ownership of the connection.

If you are weighing these options, discuss the application and workflows with us. Where AI is part of the proposed solution, our AI consulting and automation service can help examine that part of the decision. Bring the business problem and the systems you already use; the technology choice can follow the evidence.