AI makes it possible for more businesses to build their own applications. The opportunity is real. So is the responsibility for what comes next. The strategic question is whether building creates lasting capability, improves business outcomes and supports growth.

“Why are we paying for this when we could build it ourselves?”

It is a reasonable question. AI has lowered the barrier to creating software, automating processes and connecting information. Work that once required specialist development skills can now be attempted by people who understand the business problem but have little recent coding experience, or none at all.

That opens up valuable possibilities. A process that has frustrated a team for years might finally become easier. A niche requirement might be served without commissioning a substantial development project. An idea can be tested before the business commits significant money.

The danger comes when the ability to build becomes the justification for building. A convincing demonstration and a smaller software bill can make a decision look straightforward long before its consequences are understood.

Start with the business decision

The traditional preference to buy established software has always involved trade-offs. Buying can provide maintained functionality, support and access to capabilities that would be expensive to develop independently. It can also mean paying for features the business does not need, accepting awkward processes or becoming dependent on a supplier’s priorities.

Building offers greater control over how a particular problem is solved. AI makes that option accessible in more situations. It does not make every situation a sensible candidate.

Before choosing either route, leaders need to understand the outcome they are pursuing. Is the business trying to reduce processing time, improve customer service, protect margin or support an acquisition? Does the proposed application address the underlying problem, or make an inefficient process easier to tolerate?

Consider a team manually reconciling customer information across several systems. An AI-assisted application might save hours. But if the discrepancies arise because departments use different definitions, responsibilities are unclear and records are never corrected at source, the application could become another layer of reconciliation.

It might still be useful. The decision should recognise what it solves, what it leaves unresolved and whether it supports the wider direction of the business.

A licence saving is one input. It is rarely a complete strategy.

A working application creates continuing responsibilities

The first successful demonstration answers an important question: can this approach work?

It leaves several others open. Where is the data stored? Who has access? How are permissions controlled? What happens when an integration changes, a service becomes unavailable or an incorrect result reaches a customer?

These questions apply whether an application is built by an internal engineering team, an external specialist or someone in operations using an AI tool. The business still needs to understand how it is deployed, maintained, secured and recovered.

There is also a difference between an application that works for its creator and one that supports an organisation. Its creator knows which inputs to avoid, what an unusual result means and how to work around a problem. Other people may have none of that context.

Documentation helps, including documentation produced with AI. But a document does not establish that another person can operate the application, challenge its results or restore it after a failure. That capability needs to exist beyond the person who built it.

The level of assurance should match the consequences. A small internal tool used to organise low-risk information needs a proportionate approach. An application handling sensitive customer data or supporting a critical financial process demands considerably more scrutiny.

Treating every experiment like a major programme would waste the opportunity. Treating every working prototype as ready for business use would create a different problem.

AI needs human judgement around it

AI can help generate code, explore options, produce tests and explain unfamiliar technologies. Used well, it can extend what an individual or team can achieve.

Its output still needs to be assessed against the business context. An apparently sensible recommendation may rest on incomplete requirements, assumptions about the data or an understanding of the organisation that nobody has checked.

The same applies to safeguards. Leaders need evidence that access controls, validation and recovery arrangements work in their actual environment. An assurance from the tool that generated the application is not sufficient.

Experienced software engineers remain important here, but the judgement required extends beyond engineering. Someone needs to understand the operating model, commercial priorities, customer commitments and responsibilities for the information being used.

That calls for collaboration between the people who understand the work and those who understand the technical implications. Business teams should be able to explore ideas. They should also have a clear route to get advice before an experiment becomes something colleagues or customers depend on.

The aim is to make sound decisions easier, with enough challenge to distinguish a useful innovation from an avoidable complication.

Growth will test the choices

For a growing business, the decision needs to hold up beyond today’s workload. An application may work well for one team and struggle when it supports several locations, additional products or an acquired business.

Dependencies can multiply quietly. Several individually useful applications may use different customer definitions, duplicate information and rely on separate accounts controlled by their creators. Each solves a local problem while making the organisation harder to understand and support.

This matters to PE investors and portfolio leaders because a growth plan depends on the business being able to absorb change. More revenue should not require every exception to pass through the same specialist. An acquisition should not expose that critical information can only be interpreted by one person.

Technology due diligence should examine these realities alongside the architecture and security arrangements. What does the business depend on? Who understands it? What investment will be needed to support the growth plan?

Leadership matters just as much. Are people encouraged to share knowledge and seek challenge? Are responsibilities clear? Is the organisation building capability across teams, or rewarding individuals for remaining indispensable?

Those are useful questions throughout ownership. Waiting until exit preparation makes the work more urgent without making it any easier.

Make the choice deliberately

There is no universal answer to build or buy. A business may sensibly buy its core finance platform, build a distinctive customer capability and use specialist support to connect the two. Different decisions can serve the same strategy.

What matters is that each choice has a clear purpose, an accountable owner and a realistic view of its continuing demands. The assessment should include maintenance, security, support, integration and the ability to change direction, alongside the initial cost.

It should also define what success looks like. Reduced effort, better service, improved margin and greater resilience are meaningful outcomes. The volume of software produced tells leaders much less.

At Relentica, we bring technology, leadership and delivery together to help businesses make these choices and turn them into practical capability. That can mean challenging a proposed build, making better use of an existing platform or helping a promising idea become something the organisation can rely on.

AI has expanded the options. The opportunity is to choose well.

Building something because you can is an experiment. Building it because it serves the business, with the people and foundations to sustain it, is a strategic decision.