There’s a particular type of project that keeps turning up in UK organisations and going badly. It starts when a business area, operations, finance, HR, somewhere with a specific process, complains that the tools they have don’t fit how they work. IT responds by going to market. A shortlist gets drawn up. A SaaS product is chosen, procured, and rolled out. Six months later, the original complaint has not been solved. It has been replaced by a slightly different complaint, plus an annual licence bill, plus a layer of integration glue that someone now has to maintain.
This is not a criticism of SaaS in general. For commodity work, email, HR admin, expenses, CRM, buying software is obviously the right answer. The mistake is applying that logic to processes that are actually specific to the organisation, and then spending the next two years trying to bend the organisation to match the product.
Why the off-the-shelf answer keeps getting chosen
The reason is rational, at least on paper. Custom software used to be expensive, slow to build, and risky. The traditional bespoke development engagement involved months of requirements gathering, a six-figure quote, a waterfall delivery with a launch date eighteen months away, and a high chance that the business need had changed by the time the thing shipped. Against that, buying a product that someone else maintains and updates looks like the adult choice.
Except that model of custom software is largely obsolete. The economics of building apps on top of the Microsoft stack in 2026 are very different from what they were in 2016. Power Platform handles a large proportion of workflow and form-based applications with no traditional code at all. When pro-code is needed, Azure gives a developer most of what used to take months, managed databases, identity, hosting, search, document processing, in services that can be wired together in days. GitHub Copilot and similar tools have made the coding itself faster. And the delivery model has shifted to incremental releases where something useful is in front of users within weeks rather than at the end of a long waterfall.
The result is that the build-versus-buy calculation has shifted, and a lot of UK organisations haven’t updated their heuristics.
When custom genuinely is the right answer
There are a few signs that a process is probably wrong for an off-the-shelf product. If the process is something the organisation considers a source of competitive advantage, handing it to a generic tool tends to flatten that advantage. If the process is genuinely specific to the organisation’s sector or regulatory context, the SaaS options will mostly be approximations that require heavy customisation anyway, which usually ends up costing more than building from scratch. If the organisation has already bought three products in sequence and each one has ended up modified beyond recognition, the pattern itself is the signal.
There’s also the integration question. Modern organisations run on the flow of data between systems. A custom application built sensibly on Azure, talking natively to Microsoft 365, Dynamics, the data platform, and whatever third-party services are in the estate, is often materially easier to integrate than another SaaS product that expects to be the centre of its own universe.
The shape of a modern build
What a well-run custom development engagement looks like in 2026 is not what it looked like a decade ago. It’s incremental. It starts with a small, production-quality release of the highest-value slice of functionality, usually within six to eight weeks. It’s built on platform services rather than on raw infrastructure, which pushes the ongoing maintenance cost down substantially. It uses low-code where low-code fits, and pro-code where it doesn’t, and doesn’t treat the choice as a religious question. And it treats testing, release automation, and observability as part of the build rather than as things to be retrofitted later.
One UK partner’s overview of its app innovation services covers custom software development, integration, modernisation of legacy applications, and the overlap with Power Platform and mobile. It’s a useful primer for anyone trying to work out whether their organisation’s current approach is still fit for purpose. The point worth noting is how many of the services sit alongside each other. Real programmes rarely fit neatly into one bucket.
The harder question
The harder question for most UK organisations isn’t “should we build or buy?” It’s whether the organisation has the appetite to run custom applications at all. Buying a product means someone else worries about the roadmap. Building one means owning it for its lifetime, which is a commitment that boards sometimes underestimate.
That said, the organisations that get this right tend to end up with a smaller number of genuinely valuable bespoke applications that are core to how they operate, sitting alongside a sensible set of SaaS tools for everything commodity. The worst position is the opposite: a proliferation of half-fitting SaaS products, each one a compromise, and no clear view of what any of them are actually costing.
