Build or buy: replacing service management

Build versus buy is the decision organisations get wrong in both directions — building things they should have bought, and renting things they should have owned.

Here is the framework we use, and the cost model that makes it honest.

The four conditions

Build when all four hold. Three out of four means buy — the discipline matters more than the enthusiasm.

In practice all four now hold for most organisations running a fraction of an enterprise platform, which is why this decision has moved. It is worth working through them properly rather than assuming either answer.

1. Narrow, stable scope. You use a small, well-understood slice of the platform, and your processes are not being redesigned every year. If a replacement analysis finds you genuinely use most of what you licensed, buy.

2. Few, well-understood integrations. Integrations move timelines more than workflows or user counts do. If your estate has forty of them and nobody has a current inventory, you are not ready to build anything.

3. At least one person on your side who can read the code. Not necessarily a team, but not zero. If the knowledge lives only with whoever built it, you have recreated exactly the vendor dependency you were escaping — and this time with no vendor to call.

4. The maths works over five years, including maintenance. Below.

The cost model

The most common error is comparing a build's project cost against a product's licence line. Both sides carry a permanent obligation, and the comparison only means something when both are counted.

For the build side, budget 15–25% of the build cost per year, indefinitely, for maintenance. Software you own is not free to keep; it needs dependency updates, security patches, and changes as the business changes. A business case that omits this is the single most reliable way to be wrong about this decision.

Model both over five years. Three years flatters the build (the licence escalation has not compounded yet); ten flatters buy (nobody's estimate is meaningful that far out).

Where AI genuinely changes it

AI-assisted development cuts the year-zero build cost substantially for a well-specified scope. That is real, and it moves the line — scopes that were uneconomic to build three years ago are now viable.

Two things it does not change:

Maintenance. The larger lifetime cost is unaffected. A system that is cheaper to build is not cheaper to keep coherent.

The judgment requirement. AI amplifies whatever direction it is given. Sound architecture gets built faster; so does unsound architecture, in greater volume.

So AI moves condition 4 in favour of building. Conditions 1, 2 and 3 are exactly as binding as before — and condition 3 arguably more so, because generated code makes it easier to end up with a system nobody has read.

The hybrid answer

The framing is usually false. In practice the best answer is often:

• Buy a solid mid-market platform for standard incident, request and change.
• Build the two or three things genuinely specific to your business, where the product forces a bad fit.
• Integrate them properly.

This gets you a supported platform for the commodity work and ownership of the parts that actually differentiate you. It is cheaper than building everything and less compromised than buying everything.

Ask which of your processes are genuinely unusual. The honest answer is normally "two" — and those two are what your people complain about in every tool you have ever bought.

The decision in one page

Start here: what would the platform have to do? Not what does ServiceNow do — what do you run on it. Without that, this decision cannot be made honestly in either direction, which is why replacement starts with analysis and why that analysis is worth having even if you then decide to stay.

Then apply the four conditions. If all four hold, building is probably right and the guides on how apply. If any fails, buy — and the comparison narrows it quickly.