Building a ServiceNow replacement with AI-assisted development

Three years ago, "build your own service platform" was the wrong answer for almost every organisation. The cost of building and maintaining custom software was high enough that renting a platform was rational even at uncomfortable licence prices.

That is no longer true, and we are not speculating about it. We have a custom ServiceNow replacement in delivery now, built this way, and two further engagements in discussion off the back of it.

The number that matters: the client’s own business case puts the recurring saving at about DKK 3m a year — roughly €400,000, every year, against a build cost paid once. That is the arithmetic AI-assisted development changed. The same replacement priced at 2022 build rates would not have cleared the bar.

Two honest qualifications. It is a projection made when the scope was fixed, not a realised saving — the project is still in delivery, and we will publish the outturn when there is one. And the saving is that large partly because the estate was that oversized: most of what had been built was no longer used by anyone. Your number depends on your own gap between what you licence and what you run, which is exactly what the analysis phase measures.

The arithmetic changed. Most organisations have not re-run it.

What actually changed

The cost of producing working code fell sharply. A well-specified CRUD-and-workflow application — which is, structurally, what a service management platform is — can now be built by a small team in a fraction of the time it used to take.

That matters most for exactly the kind of scope a platform replacement produces. The analysis phase of a replacement typically finds that a fraction of the old estate is genuinely in use: a handful of workflows carrying real volume, a defined set of integrations, a clear data model. That is a narrow, well-understood specification — which is precisely the situation where AI-assisted development is strongest.

It is much weaker where requirements are vague, the domain is unusual, or nobody can say what "correct" looks like.

Why most attempts still fail — and ours do not

AI does not supply judgment. It amplifies whatever judgment is directing it, and it amplifies in volume. That is why the same tooling produces both a platform an organisation runs on for a decade and a prototype that collapses in month four.

The difference is entirely in the discipline around it. These are the failure modes we design against from day one:

Plausible code that is subtly wrong. Generated code reads confidently. Wrong assumptions about permissions, transaction boundaries, or edge-case behaviour are not visually obvious, and they surface in production rather than in review.

No consistent architecture. Generated a feature at a time, a system drifts. Three different patterns for the same problem, four ways of handling errors, state managed inconsistently. Each piece works; the whole becomes unmaintainable, and it happens faster than it used to because the code arrives faster.

A data model nobody designed. This is the expensive one. If the schema emerges feature by feature rather than being designed up front, you get a structure that fights every subsequent change. Data models are hard to fix later in any system, and in a service platform they are the system.

Security and permissions modelled by default. Who can see which records, which fields are restricted, how approvals are enforced — these need deliberate design. Defaults are rarely right, and they are rarely obviously wrong either.

Nobody understands the system. The worst outcome, and the most ironic: you leave a proprietary platform to escape dependency, and end up with a codebase no one on your side has read. That is not ownership. It is a new lock-in with no vendor to call — which is why we build with your people in the room throughout, not as a courtesy but as the point.

What makes it work

Five things have to be true. They are not exotic — they are ordinary engineering discipline, which is exactly what gets skipped when code arrives quickly, and exactly why most attempts disappoint.

Notice that none of these are about AI. They are the practices that made custom software viable before, applied to a process that now moves considerably faster — which makes them more important, not less.

Where this now lands

For organisations paying enterprise platform prices for a narrow slice of capability — which is most organisations on ServiceNow — building is now the better economic answer, and it is no longer a close call. You get a platform shaped around how you actually work, no licence bill that grows with your headcount, no jurisdiction question, and an asset you own rather than rent.

That is the position we take into the room, and we take it because we are delivering it, not because it sounds bold.

Two honest limits remain. If your usage genuinely is broad — you use the breadth of the platform and get value from it — renting is still right, and we will say so in the first conversation rather than the fourth. And if nobody on your side can hold a system design in their head, that is a gap to close before you start, not a reason to hand the problem to a vendor instead.

What we will not do is pretend that pointing an AI at a requirements document produces a service platform. It produces something that demos well and falls over in month four. The gap between that and a platform you run on for a decade is engineering judgment — the part that has not been automated, and the part we are actually for.

Where this fits

This is how we run the development phase of a ServiceNow replacement: AI-assisted throughout, with the scope discipline from the analysis phase and review discipline applied to every line. Fast, and boringly well-engineered.

If you are still deciding whether to leave at all, start with why organisations leave ServiceNow. If the answer is yes, migrating off ServiceNow sets out the sequence.