AI Coding: When Custom Development Became Cheap and Governance Became Expensive

The question of build or buy appears even more frequently today than a few years ago. Boards and C-Level management talk about Vibe Coding and Software Delivery and push this down the stairs.

We at Teiva Systems also see this when assessing typical enterprise platforms, like service desk, HR workflows, and similar. A task force produces a serious capability map, hands it upward, and the whole map comes back resolved into one decision. License a platform, or build it internally. Forty or fifty distinct capabilities, one answer.

That compression was always rough. It has become expensive because custom development with AI has changed the cost of producing software without changing the cost of owning it. Those two numbers used to move together. They no longer do, and most business cases are still written as if they did.

Key takeaways

• 35 percent of enterprise teams have already replaced at least one SaaS tool with software they built themselves, and 78 percent expect to build more in 2026 (Retool, 2026).
• Gartner places agentic AI at the peak of inflated expectations in its 2026 Hype Cycle for AI in ITSM, and advises verifying incumbent platform capability before buying an add-on or building a replacement.
• A large majority of ITSM buyers license capability they never implement. Both over-buying and over-building come from the same error: one decision taken for an entire estate.
• Our own measured build: 116 story points in seven calendar days, five AI agents and one human architect, zero defects escaped to done.
• The constraint has moved from producing software to verifying and owning it. Generation got cheap. Governance did not.

The map arrives, and the decision collapses

The architecture work is usually good. Business capabilities mapped, components identified, APIs and dependencies documented. It survives internal review on its merits.

Then it goes up a level and becomes a single line item. That is where the value leaks. Incident management and a capability that encodes how your business actually earns money have nothing in common except a place on the same slide. They carry different risk, different integration surface, different rates of change. Scoring them together guarantees that one of them gets the wrong answer.

What custom development with AI actually changed

Producing custom software is cheaper than it was eighteen months ago, and not marginally. For example, a custom Service Desk tool or an ESM platform typically uses a common data model, and the ITIL framework is well known. To vibe code this is not a technical problem.

Retool’s February 2026 report on the shift, based on a survey of 817 builders and enterprise professionals, found that 35 percent of teams have already replaced at least one SaaS tool with something they built, and 78 percent expect to build more internal tools this year. Workflow automation and internal administrative tooling lead the replacement list. Is exactly the territory an ESM platform occupies. About half of the builders shipping AI-assisted production software reported saving six or more hours a week.

The vendor sells the build side. A survey of an application generation vendor’s own customers is not a neutral instrument, and we say so rather than quoting the number bare. We use it anyway, because the direction matches what we see in delivery. Work that credibly took a quarter now takes a fortnight.

The same report carries the part that usually gets skipped. Sixty percent of respondents built software outside IT oversight in the past year. Seventy-five percent now work under an AI directive from above, but 35 percent of their organisations have no productivity metric for it at all, and only 19 percent describe their automation maturity as advanced. The capability arrived faster than the control around it.

What did not change

Gartner’s Hype Cycle for AI in ITSM, published in June 2026, places agentic AI at the peak of inflated expectations. The practical guidance inside it is unglamorous and correct. Before buying an AI add-on or building a replacement, verify whether the platform you already run covers the need, and price the licensing and implementation properly if it does not. That is an instruction to evaluate per capability, not per platform.

The licensing side fails the same way, in the opposite direction. Gartner’s market guidance on ITSM platforms has been consistent that most buyers pay for capability they never implement, and its January 2026 work on rightsizing projects material overspend by 2029 for organisations that size the purchase wrong. Nobody over-buys because a platform was bad. They over-buy against a feature wish list rather than against what their team can operate.

Two failure modes, one root cause. The decision was taken once, at the wrong altitude, and never revisited as the workflows underneath it diverged.

Score the capability, not the platform

The useful version of this exercise scores each capability on the map separately. Six questions carry most of the weight.

1. Differentiation. Does this capability look the same at every company in our sector? Incident, request and change management differentiate nobody.
2. Integration surface. A capability touching six upstream systems carries integration cost that dwarfs the capability itself, and that cost lands on whoever owns it.
3. Regulatory exposure. Anything that will be audited needs a decision trail. A licensed platform and an internal team answer that question very differently.
4. Data gravity. Where the data already lives decides more architecture than architecture does.
5. Rate of change. Capabilities that change quarterly reward ownership. Capabilities untouched in a decade reward licensing.
6. Five-year ownership. Who operates this after the current team has moved on, and can they reconstruct why it works the way it does?

Run those six across a real map and the buy or build question stops being binary and becomes a distribution. In our experience the commodity service management core licenses itself decisively, and two or three capabilities carry enough differentiation to justify owning them outright. The real engineering sits in the boundary between the two, not in the choice.

Two contrasting patterns, both composites rather than named clients. A manufacturer with an ordinary IT service estate and one genuinely unusual field service model licensed everything standard, built the field model, and the build turned out to be the smaller line item. A financial services firm had the reverse profile: an ordinary service management need with an unusual compliance evidence requirement, and the right answer was a licensed platform with a thin custom evidence layer above it rather than either extreme.

What custom development with AI costs us, measured

We run an AI-augmented delivery process ourselves, so the honest move is to publish what it produces rather than describe it.

One build we can put full numbers against. A multi-agent delivery system including its infrastructure and its identity and access layer, delivered between 17 and 24 July 2026. One hundred and sixteen story points across four sprints in seven calendar days. Five AI agents covering build, QA, UX, architecture and orchestration, plus one human architect, for the entire delivery stream rather than per feature. Sprint velocity was 100 percent on three of four sprints and 89.7 percent on the fourth, with the gap logged and carried rather than absorbed. One sprint of 29 points, planned for seven days, closed in eight hours and twelve minutes from start to QA sign-off, because nothing waited in a queue for a handover.

The quality numbers matter more than the speed numbers. Four bugs found across 116 points, every one caught by independent QA re-verification rather than by trusting a build report. Zero defects escaped to done. First-pass acceptance criteria pass rate of 88.9 percent, measured rather than estimated. Every figure comes from a timestamped gate record, not a retrospective written afterwards. We describe how that verification layer works in Who tests the AI-generated ServiceNow apps, and how the delivery team is structured in Inside an AI Delivery Team.

Now the limitation, because it is the reason to publish any of this. That build is a web application, not a ServiceNow instance. The platform differs. The process and its evidence trail do not. We show this one because it is ours to show in full today.

What the numbers demonstrate is not that building has become easy. It is that the constraint moved. Production is no longer the bottleneck. Verification is, and verification did not get cheaper when generation did.

The bill that arrives in year three

Custom builds delivered with AI rarely fail at delivery. They fail later, and quietly.

Year one, the system works and the team that built it is still there. Year two, the model landscape has shifted underneath it and something needs re-architecting. Year three, the architect who governed the agents has moved on, the reasoning behind a dozen consequential decisions exists only in a chat history nobody exported, and an auditor asks a question that requires reconstructing intent from code.

This line item never appears in the business case. The cost of a custom capability is not what it took to generate. It is what it takes to explain, operate and defend for as long as the business depends on it. A licensed platform amortises that cost across every customer the vendor has. An internal build does not, unless the delivery process was designed to produce the evidence as it runs.

That is why we gate every phase and log every decision with an owner and a reason. Not as a compliance gesture. Because a process that produces its own audit trail is the only version of custom development with AI whose cost we are willing to quote past year one. Under the EU AI Act, systems that matter are expected to keep records that can be inspected after the fact, and a delivery model that logs each gate produces them by construction rather than in a scramble. The wider control problem is covered in Why Every Enterprise Will Need an AI Control Tower by 2027 and the identity side in Securing Enterprise AI Agents.

Where this leaves an architect holding a capability map

Do not take one decision for the whole estate. Score each capability against differentiation, integration surface, regulatory exposure, data gravity, rate of change and five-year ownership. Expect a split answer. Design the boundary between the licensed core and the owned capabilities deliberately, because that boundary carries the real engineering risk.

We are a ServiceNow Premier Build and Design Partner and we run an AI delivery practice. We earn either way, which is exactly why we are willing to tell a client that two thirds of their map should be licensed and left alone. Our position on where an AI build agent helps and where a human still wins is set out in Build Agent vs. Traditional ServiceNow Development.

If you have a capability map and a decision to make, bring us one capability from it. We will run it through the scorecard, and if it lands on the owned side, through the delivery process, so you can judge both on your own work before committing to either.

Start with a Gen AI Assessment or book a free consultation.

Sources

• Retool, The Build vs. Buy Shift: How Vibe Coding and Shadow IT Have Reshaped Enterprise Software, February 2026. Report and announcement.
• Gartner, Hype Cycle for AI in ITSM, 2026, ID G00846344, June 2026.
• Gartner, Predicts 2026: AI’s Transformative and Disruptive Path in ITSM. Gartner.
• Gartner, market guidance on ITSM platforms and rightsizing, 2025 and January 2026.
• Gartner, Magic Quadrant for AI Applications in IT Service Management, 2026, in which ServiceNow is named a Leader. Report access.

Frequently asked questions

Has AI made custom development cheaper than licensing a platform?

Cheaper to produce, yes. Cheaper to own, no. Generation cost fell sharply. Verification, operation and evidence cost did not, and those dominate total cost from year two onward. The comparison only works per capability, not across a whole estate.

How do we decide which capabilities to build and which to license?

Score each capability against six criteria: differentiation, integration surface, regulatory exposure, data gravity, rate of change and five-year ownership. Commodity service management usually licenses itself. Capabilities encoding how the business earns money often justify ownership.

What is the biggest risk in custom development with AI?

Not delivery. Year three, when the people who governed the agents have moved on and nobody can reconstruct why a decision was made. A delivery process that logs each gate with an owner and a reason removes that risk by construction.

Does building with AI weaken governance or compliance?

Only if speed comes from skipping steps. In our process it comes from removing queues. Every phase keeps an entry and exit contract, and each transition produces a timestamped record, which is also what the EU AI Act expects for systems that matter.

Can you show real numbers from an AI-augmented build?

Yes. 116 story points across four sprints in seven calendar days, five AI agents plus one human architect, four bugs found by independent QA, zero defects escaped, 88.9 percent first-pass acceptance. That build was a web application, not a ServiceNow instance, and we keep that distinction visible.

Kostya Bazanov, Managing Director, Aug 27, 2026

Eager to take the next step? Contact us today!

Privacy policy (GDPR)

* Required fields

Submit