Author
TL;DR: Custom AI tools are the most seductive offer in consulting right now: we build it, you own it, no recurring fees. The instinct is right: you should own your tooling. But what you own the day the engagement ends is not a capability. It is a codebase, its dependency tree, and a decay clock set by the model providers, with no product team behind any of it. Owning your AI tools is the right goal; owning a consultancy’s custom code is the wrong way to reach it.
The pitch arrives in some version of this shape: we will build AI tools tailored to your business, on your data. When we leave, they are yours. No vendor. No licensing fees. No dependence on anyone.
Almost everything about that pitch deserves to land. The ownership instinct is correct: your commercial tooling embeds how you price, how you quote, and how you decide, and handing that to an outsider on rented terms should make you uncomfortable.
So take the offer seriously. Then ask what, precisely, you will own.
Owning Custom AI Tools Is Not Owning a Capability
A capability is code plus the team that keeps it current. Strip the team away and what remains is an artifact. It does today what it did yesterday, in a world that has moved.
This is not a new discovery. The classic empirical surveys of enterprise software, peer-reviewed and repeated across decades, found the same thing. Most of the lifetime cost of software arrives after it ships, in the long tail of fixes and adaptations. Later work added a compounding clause: the more complex the codebase, the more every subsequent change costs. Maintenance is not the epilogue of a software project. It is most of the story.
Custom AI tools sharpen that old finding into something faster. A conventional internal tool decays on your clock, when your processes change or your systems migrate. A custom AI tool decays on the model provider’s clock as well. Model APIs deprecate in months, not years. Context limits move. Inference pricing changes underneath the tool, sometimes with a printed expiry date. The consultancy’s deliverable is frozen against that moving substrate. The freeze is invisible on demo day, because on demo day the substrate has not moved yet.
“No licensing fees” is an accounting statement. Read it as one. The license was priced at zero. The maintenance was priced at nothing, which is not the same as costing nothing. It means the cost was left off the page.
The Maintenance Ledger Nobody Prices Into Custom AI Tools
Four lines never appear in the custom-build proposal. Each one becomes somebody’s problem within the year.
Who ships the fix when the substrate moves?
When the model API your tool was built on deprecates, someone rewrites the integration. On a product, that someone is the vendor’s engineering team, and the fix ships to every customer at once. On a custom build, that someone is you, at whatever rate your consultancy charges for the return visit.
Who patches it?
A tool wired into your CRM, your billing system, and your data warehouse is part of your security surface. Custom code has no security team. It has whoever remembers how it works.
Who remembers how it works?
Case-study research on enterprise software customization found that modifications touching core functionality carried the heaviest long-term maintenance burden. Custom code was sometimes rewritten wholesale after a vendor upgrade. Even cosmetic changes proved deceptively expensive: in one documented implementation, keeping renamed fields and rearranged screens alive consumed more than half of one administrator’s working week, because upgrades kept wiping them out. Now transplant that finding into a stack where the upgrades come from model providers on a quarterly rhythm.
Who decided this would live?
Peer-reviewed studies of abandoned software projects keep converging on the same answer: projects die on organizational causes far more often than technical ones. The tool worked. Nobody owned it. We see the ending regularly in the gap between pricing recommendations and pricing operations. The deliverable that was going to change how the company decides sits untouched two quarters later, because maintaining it was nobody’s job. There is a word for custom software in that state, and the word is shelfware.
A pattern we watch for, because it repeats: the rebuild that never happens. The custom tool misfits your stack, so the plan becomes “we’ll rebuild it properly on our side next year.” Next year the bandwidth is not there. The plan is short for shelfware, with a delivery date attached.
I have lived the other ending. The software company I ran knew by 2008 that a rebuild for the cloud was inevitable, and the plan waited the way these plans wait. It took the market crash to force our hand into pulling the trigger. The rebuild that finally happens is usually the one a crisis schedules for you.
The risk runs at platform scale too. Salesforce closed CPQ to new sales in 2025 and pointed the roadmap at its successor, so every custom build sitting on CPQ now lives on a substrate with a sunset horizon. Plenty of those teams will be caught flat-footed when the deletion lands. And a product at least retires with an announcement and a migration path. Custom AI tooling gets neither. Its substrate just moves.
Where Does Your Pricing Architecture Actually Stand?
A few questions return your pricing architecture score and show which of your licensing, packaging, and pricing decisions needs attention first. Real diagnosis, not a mailing-list toll.
What Owning Your AI Tools Should Mean
You should build. Your team, your stack, your judgment about what your commercial motion needs. A tool that runs pricing decisions has to speak to your CRM, billing, and entitlement systems, in the language your engineers already run. A codebase in a language your team does not run fails the fit test on delivery day.
The question is what you build ON.
The same customization research that documented the maintenance burden carries a mirror finding, and it is the interesting one. Where a customization was absorbed into the vendor’s standard product, its direct maintenance cost disappeared. The buyer kept the capability. The vendor’s roadmap carried the upkeep. Maintenance did not vanish; it moved to the party structurally built to hold it, a product team that ships the fix to everyone at once.
That is the whole argument in one sentence: own the assembly, not the foundation. Build the tools that encode your judgment on primitives a professional product team maintains, so the substrate moving is somebody’s day job instead of your standing liability. We describe it as Lego kits rather than castings: engineered, versioned pieces kept current by people who do nothing else, and what you snap together on top of them is entirely yours.
That is why LevelSetter is built by a dedicated product team, not as a rack of bespoke client codebases. We built our own commercial engine the same way before asking anyone else to. The judgment stays human. The foundation stays maintained. Trouble starts whenever one party ends up holding both jobs.
We staffed it with dedicated developers instead of billing those hours as consulting for the same reason. One-time code solves a client’s problem no better than a spreadsheet model; the hard part of a transformation is making it operational. Custom builds, client by client, cannot derive patterns. A platform can. Every deployment teaches the pattern library something; the learning compounds, and outcomes keep getting better because of it.
A story from our own client work, told without names. A product manager recently built a pricing scenario tool with an AI coding assistant. Two weeks, part time, and genuinely good: it answered questions at the speed he could ask them. Then he said the quiet part unprompted. He was not in the business of building commercial modeling software. He did not want to spend a token budget refining it. What he wanted was an out-of-the-box tool he could augment to his team’s needs.
He had found the boundary this article is about, from the inside. The build that teaches you is worth every hour; the build you must keep alive is a job nobody applied for. The DIY-lane test is the same: not whether your team can build, but whether what they build has a product team behind it on the day the substrate moves.
Six Tests to Run Before You Sign a Custom AI Build
Put these to any consultancy proposing custom AI tools. None are hostile. All are clarifying.
- When the model API this is built on deprecates, who ships the fix, on whose budget? If the answer is a change order, the recurring fee did not disappear. It converted to an unscheduled one.
- What happens to the tool the day the person who built it rolls off? A capability that exits with an individual was never yours.
- Is there a roadmap that exists independent of your invoices? Products improve because a team is paid to improve them for everyone. Custom code improves when you notice it fell behind, and pay.
- What exactly did “no licensing fees” price at zero, and what did it leave unpriced? Ask for the maintenance line. The reaction to the question is itself information.
- Can your own team change it without a change order? Real ownership means assembly you control, in the stack you run, integrated with the systems your commercial motion already lives in: CRM, billing, entitlement.
- If you had to rebuild it in eighteen months, what did today’s fee buy? Sometimes the answer is “the learning,” and that can be worth the fee. Buy it knowingly.
The Decision Underneath the Tooling Decision
Every test above points at the same upstream question, and it is not a technology question. What should your pricing tooling encode? Which decisions does it automate, which does it inform, and where does human judgment hold authority? That sequencing runs through everything we have written about how AI software should be priced. It is judgment work before it is engineering work. A tool that encodes the wrong commercial logic decays faster than any API can deprecate it, because it was wrong on the day it shipped.
If you are weighing a custom AI build against building on a maintained foundation, describe the decision to a pricing expert before you sign either way. A pricing expert replies, not a form.
