Make or Buy? AI is Changing the Balance

In a recent customer portal project, we used AI for much of the coding after defining the project's building blocks and design system. Comparing different parts of the project completed with and without AI, the team roughly estimated a saving of 30–40% in development hours. It made a familiar decision feel different: how much weight should we now give custom development when choosing between Make and Buy?

I expect AI to shift that balance gradually towards Make, especially when small and medium-sized software systems need to be introduced or replaced. A focused custom solution is becoming a more attractive option. But faster coding changes only part of the calculation. The processes, the integrations, and the company's ability to operate the result still determine whether building is the right decision.

The full cost of buying and building

The price of a software licence is always only part of the expenditure of buying. A product still needs to be configured, connected to existing systems, and introduced into daily work. Data must be migrated, processes adapted, and exceptions handled. Custom software also requires ongoing effort for improvements, maintenance, and operation. AI changes the development effort within that comparison, so both options deserve a fresh look at their full cost over time.

In one Salesforce introduction, workarounds and add-ons accumulated to preserve the sales team's familiar routines. Over time, process steps and integrations became clumsy, and newer CRM features were difficult to use. The effort of keeping the old process limited the value of product updates.

A bought product can also help a company learn how the work could be organised and speed up the introduction of the software. Teams do not always know their requirements clearly enough to design a useful custom tool. A mature product gives them a working process to examine and adopt. The important decision is which conventions to accept, and which specific needs are valuable enough to justify a different approach.

Finance and accounting often benefit from established software that supports local requirements and customary ways of working. Maintaining those capabilities in a self-built system takes continuing effort, with limited benefit from doing the work differently. A customer portal presents a different case: its workflows, branding, and connections to other services may shape the customer experience. There, building around a clearly defined and improved process can create value beyond matching a standard product's features.

Software that grows with the business

A focused build starts with the capabilities the business actually needs right now, then grows as those needs become clearer. That often is preferable to introducing a broad product and working around the parts that do not fit. In the portal project, adding ecommerce later just extended the existing system.

AI delivers the same kinds of benefits during ongoing changes as during the initial build, reducing the programming effort of adapting and extending the portal. Sustaining those benefits also means keeping our AI development setup up to date and refining how we use it. That upkeep takes time, but it also brings further improvements to the way we develop and change the software. It is part of the cost of owning a self-built solution, alongside the effort AI saves.

A company can also combine the two approaches: buy a dependable core for common tasks and build the parts that make its service distinctive. Before introducing another application, it is worth checking whether an existing tool can be modified instead. The aim is to improve the whole flow of work, with clear connections between systems and a definition of the authoritative system for the information they share.

Take responsibility for what you build

Easier development can also lead to developing more than a company can comfortably operate. Each additional tool brings dependencies, integrations, and changes that can fail. Someone must keep it secure, detect problems, support users, and restore service when things go wrong. An internal team should own those responsibilities, with help from an experienced partner where needed. Companies that are already good at operating software may be able to take advantage of cheaper development sooner.

The development hours saved in the portal project are only one part of the equation. People still have to steer the product direction, define the work, validate the results, and improve the solution. To judge the decision over time, you need to look at how easily the solution changes, how many manual workarounds remain, what it costs to maintain, and how well it serves customers. Those outcomes determine whether we achieve better business results alongside faster development.

Start with a clear need

For the next software introduction or replacement, start by being clear about what you need. Define the problem, examine and improve the process, and establish what the software must do. Decide where adopting a standard way of working is useful and where your own approach creates value. Then compare buying, extending an existing tool, and building against those requirements, including integration and long-term operation.

The comparison will favor Make more often as AI reduces development effort, particularly for small and medium-sized systems. The shift will be gradual: organizational habits and trust take time to change, and successful projects will build confidence in owning bespoke software. As building becomes a viable option in more situations, clarity about the business need will help determine when to buy, when to extend, and when to build.