The build or buy question has a boring answer

Buried in the Government Digital Service guidance that every department must satisfy to get technology spending approved is a sentence that ought to be printed on the wall of every procurement office in the country. Discussing off-the-shelf products, it observes that even small modifications to OTS software can remove most of the benefits of using it.

That is the build-or-buy decision in twenty words, and it explains the majority of bad outcomes in workflow automation. The failures are rarely a straight build that should have been a buy. They are purchases that were then customised until the organisation owned all the disadvantages of building and none of the advantages of buying, while still paying the licence.

The Technology Code of Practice is worth reading whether or not you work in the public sector. It is short, it is free, it is used for the Cabinet Office spend control process, and its eleventh point is the most disciplined statement of the purchasing question published in Britain. Nobody in the private sector is obliged to follow it. Everybody in the private sector would benefit from being asked its questions by their own board.

The test, as written

Point 11 was first published in November 2017 and last updated in November 2023. It sets out when to build.

Build if the user need is unique or rare, meaning a service only your organisation provides. Build if there are few suppliers who can meet the requirement. Build if you cannot scale, adapt or integrate available commercial products to meet your core needs. Build if you need to own the technology to keep the flexibility to modify it. And build only if you have access to the capability and resources to manage the project.

Then when to buy. Buy if there is a commercially available way to meet most of your user needs. Buy if suppliers can configure settings or features to meet them. Buy if you do not need a high level of customisation or bespoke changes. Buy if the specialist expertise and support you need is commercially available. And buy only if your organisation has the capability to support what it purchases.

Read those two lists against a typical workflow automation requirement, and the answer arrives fast enough to be disappointing. Approvals, routing, forms, notifications, escalation, audit trail: none of that is unique or rare, all of it is commercially available, and there are dozens of suppliers. On the published test, you buy. The boring answer is usually the right one.

The interesting part is what happens next.

Buy the runtime, own the rules

A workflow automation product is two things sold as one. There is a runtime, which schedules work, holds state, retries failures, records what happened and integrates with your identity provider. And there are your rules, which encode the specific way your organisation decides things: who approves what at which threshold, which cases skip a step, what happens on the fourteenth day.

The runtime is a commodity. It is genuinely hard to build well, it is well served by the market, and building your own is the sort of decision that looks defensible for three years and indefensible in the fourth. The rules are not a commodity. They are a description of how your organisation works, they change constantly, and they are the only part of the system that could not be replicated by a competitor.

The Technology Code of Practice puts this in contractual language, and the phrasing is unusually precise for a procurement document. Contracts must be explicit about ownership of intellectual property in the delivery of a technology service, and it spells out what that includes: software code and the business rules that process information between user interfaces and stored data.

Business rules. In a workflow product, those rules are typically expressed in a proprietary designer, stored in a proprietary format and executable only inside the vendor’s runtime. If your contract does not address who owns them and in what form you can take them away, you have not bought a tool. You have rented the ability to describe your own processes, and the rent is reviewed at renewal.

The same guidance recommends, where economic, a break clause at a maximum of two years allowing termination with minimal exit costs. That is the clause a workflow vendor will resist hardest, and it is the one that determines what your renewal conversation feels like.

Exit is the part nobody prices

Every organisation that has replaced a workflow platform describes the same experience, and it is never the runtime that hurts. It is that four years of accumulated rules, forms, routing tables and integration mappings exist only inside the outgoing product, in a format designed to be edited there and nowhere else.

The Technology Code of Practice also asks buyers to be explicit about ownership of government data, including data created through the operation of the service. Read that clause across to a commercial context and it covers more than records. The audit trail of who approved what and when is data created through operation, and in a regulated organisation it may need to outlive the contract by years. A workflow platform holding your approval history is holding evidence, and evidence that cannot be extracted in a usable form is evidence you do not really have.

Two tests settle this before signature and neither is expensive. Ask the supplier to export a complete process definition, including rules and routing, in a documented format, and have somebody technical look at what comes back. Then ask for an export of a year of execution history with the same scrutiny. A vendor confident in its product will not object. A vendor whose commercial model rests on the difficulty of leaving will explain why the request is unusual, and that explanation is the answer.

The guidance’s advice to routinely challenge sourcing strategies and to check whether smaller suppliers could compete only works if leaving is possible. Otherwise a renewal is not a negotiation, it is a formality with a price attached.

Two questions that decide it faster than any matrix

Most build-or-buy exercises produce a weighted scoring matrix, and most weighted scoring matrices produce whatever answer the person who chose the weights intended. Two questions are more informative.

The first: how often does this process change, and who changes it? If the answer is monthly, and the person who changes it sits in operations rather than technology, you need a product whose configuration surface is genuinely usable by that person, and you should test that claim during a trial rather than accept it in a demonstration. The Technology Code of Practice suggests exactly this, recommending that a product trial should try to solve one small but hard problem, test integration with your current products, and test how the product fits your deployment pipeline.

The second: what is the cost of being wrong for a year? Not the cost of the licence. The cost of running a process badly, or not at all, for the length of time it would take to replace the decision. For a payroll workflow that number is large and it argues for buying something proven. For an internal request queue it is small and it argues for building something cheap and disposable, which is a legitimate answer that scoring matrices almost never produce.

Metered pricing has changed the buy side

The buy case used to rest on cost certainty. A licence was a fixed number, and building was the option with the open-ended bill.

That is no longer reliably true. Vendors have moved to consumption pricing, and the terms carry consequences that a fixed licence never did. Take one published example. Microsoft’s documentation for Copilot Studio says that capacity is enforced monthly, that whatever you have not consumed by the end of it is lost rather than banked, and that going beyond what you bought can trigger technical enforcement and, in the end, a refusal to serve.

Neither term is unreasonable. Both are new. A bought workflow platform can now stop working because demand was higher than forecast, which is a failure mode that a self-hosted queue does not have, and it belongs in the comparison alongside the licence cost. The Technology Code of Practice already anticipates the shape of this, advising that contracts should include usage-based billing models where appropriate and where this represents best social value for money.

Read the whole clause, not the first half of it. Social value is a defined concept in British procurement with its own policy notes and its own minimum weightings, so the test the guidance sets for metered billing is not simply whether it is cheaper. Appropriate is doing a lot of work too. Usage-based billing is appropriate where usage is discretionary. It is considerably less appropriate for a statutory process that runs whether or not you budgeted for the volume.

What British firms are actually doing

The Office for National Statistics asked businesses how they adopt AI, and the pattern by industry is instructive. Manufacturing, wholesale and retail, accommodation and food services, and administrative and support services most commonly report using free-to-use software. Construction, information and communication, and professional, scientific and technical activities more often report purchasing external software or ready-to-use services.

That is not a build-versus-buy split. It is a buy-versus-borrow split, and the borrowing end is where the ungoverned automation lives: free tools adopted by a team, holding real business rules, invisible to procurement and to the information security function. Every organisation with a serious workflow estate has some, and finding it is usually more valuable than the next platform decision.

The AI and automation category carries this subject alongside what automation costs to run, which takes the same question from the operating budget rather than the purchase order. The evidence on which automations survive long enough for any of it to matter is in the five RPA applications that lasted.

The reason the answer is boring is that the interesting part was never the tooling. It was whether anyone had written down how the process works clearly enough that a machine could follow it. Organisations that have done that can buy almost anything and succeed. Organisations that have not will fail with a product and fail again with a build, and will conclude both times that they picked the wrong platform.