When code gets cheap: what happens to the vendors?

When code gets cheap: what happens to the vendors?

Anyone who has sat through a vendor meeting knows the answer: "it's on the roadmap." For twenty years that was an honest answer. Building an exhibitor module, or an integration with an accounting system, genuinely cost weeks of developer time, and a vendor with three hundred customers had to choose between them.

It doesn't cost weeks now. It costs days. Which makes the roadmap a weaker answer than it was last year, without many buyers having started to treat it that way.

(So this post is not about AI inside your system — agents, suggestions, automatic draft quotes. We've written about that distinction elsewhere. This is about AI in the production of the software, at the vendor, before you ever see any of it.)

Why the big ones still aren't running

I have sat on both sides of that table, first for years as the person buying these systems, now as the person building one. What I assumed from the buying side was that vendors were slow because they were comfortable. Sometimes that is true. But it isn't the main explanation, and I was wrong about where their cost actually sits.

An established vendor's cost has never been in writing features. It's in not breaking the several hundred installations already running, each with its own configuration, its own rate codes, and its own peculiarities that someone added because a customer insisted in 2014 and nobody has dared remove since.

Think about what a small change actually sets off for them. An adjustment to how a line is priced has to be tested against a certified accounting integration, against EHF, against the SAF-T export, against a VAT rate that changed last year and another that changes next year, and against those hotels still running a version that's two years old because they never upgraded. And it has to happen without a receptionist somewhere standing at eleven thirty at night with a bus and forty people and nothing working. AI will write that change in a quarter of an hour. It removes none of the testing around it.

Then comes the part I find genuinely counterintuitive, and which runs directly against how this is being sold: AI assistance helps least where the code is oldest. The pitch says AI can clean up legacy code. In practice the bottleneck in a fifteen-year-old system isn't writing, it's figuring out what's already there. What does this function do? Who calls it? What falls over at the other end if I change it? An AI assistant is good at proposing a change and fairly bad at knowing the consequences in a system nobody has mapped. So the vendor with the most legacy gets the least out of the tool, even though they're the ones who need it most.

I'm not sure how long that lasts. The tools are getting better at exactly this, quite fast. But it's where we are now.

What has actually gotten faster?

Integrations, mainly. Talking to an API, mapping fields, handling error states — that's the most mechanical part of the work, and it's what AI is best at. "We don't support that accounting system" holds up poorly as an answer now.

The same goes for getting data out. Export tooling has always been underinvested in, for the simple reason that no vendor makes money on it. It's now cheap enough that price isn't a legitimate excuse, which is worth remembering the next time you ask what an extraction costs.

And audit, which is the least discussed consequence of all this. If a machine can write a module in a day, it can also read through an entire system and say where a check is missing. That means "it would take months of consultant time to figure that out" is no longer true. You can ask for a dated review of one specific thing and expect an answer.

Code that looks right

Here is the risk no vendor markets, us included.

The old failure was code that didn't work. It got found, precisely because it didn't work. The new failure is code that works perfectly well in the case it was written for.

An example. A vendor discovers that a user can see figures she shouldn't, in one particular report. You ask an AI assistant to fix it, and it adds a check to exactly that report, quickly and neatly. The problem is that the same data retrieval also happens in an export, in an API endpoint, in an email that goes out every morning, and in an overnight job nobody has looked at since it was written. The check is in one of five places. The fix looks finished and isn't, and that kind of half-done is harder to spot than a straight crash, because nothing complains.

This hits new and old vendors in exactly the same way, and the net effect on the market is fairly predictable: more features, faster, with worse coverage at the edges. For a buyer it means release velocity has stopped being a quality signal. Everyone has it now.

"But you told us not to build it ourselves"

We did, and we stand by it. It's fair to ask how that squares with us using the same tools, so let me answer it.

The point in that post was never that hotels can't write code. It was that building is roughly twenty percent of the work over time. The eighty that remain are maintenance, regulation that moves, integrations that break when the other side updates something, and someone answering the phone on a Saturday. AI does something about the twenty percent and almost nothing about the eighty. So the question is never who writes the code, but who carries the rest, and whether they carry it as a business or as a side task for one enthusiast in IT who eventually changes jobs.

It follows that AI-assisted development doesn't make anyone a credible vendor. It lowers the bar for building something that looks complete in a demo. It doesn't lower the bar for running it for five years. I'd expect a handful of new names in this market over the next couple of years that are impressive in March and gone by October, and that's a new variant of the consolidation risk we've written about before.

What to ask instead

Feature lists are becoming poor grounds for a decision, simply because they're cheap to extend. What still costs something is the discipline around the code, and you can ask about that without being technical.

Take something concrete and ask where it's enforced. For instance, that a price can't be set outside an agreed range: is that checked in one place, or at every place it can happen? "It's validated throughout the system" isn't an answer to the question. "It goes through one function, and that function has a test" is.

Ask about rollback rather than release cadence. A vendor shipping weekly with no way back is riskier for you than one shipping monthly who can undo it.

And ask what they've removed in the past year. This is the question I like best and also the one I'm least confident works, because most salespeople don't understand it and answer past it. But if you get a developer in the room and she starts talking about code and documentation they've deleted because it no longer matched reality, you've learned something real about the vendor.

The honest caveat

We're a young vendor building with these tools, so we have an obvious interest in saying code has gotten cheap. Read it with that in mind.

What AI hasn't given us is fifteen years of references, certified integrations with every Norwegian accounting system, round-the-clock support, or the collection of edge cases that only appears once a hundred hotels have used something for a decade. The established vendors have all of that. It's probably the strongest argument against us in a procurement process, and we have no good counter to it other than time.

What we think we do have is breadth early, and room to move faster on event production than a software vendor protecting a large installed base. But breadth built fast is a claim, not a property, and the only honest way to treat a claim is to let it be tested. That's why we put at least as much of these tools into auditing what we've built as into building more. It's the dull half of the job.

So what do you do with this

Not much, honestly, until the next time you're sitting in a vendor meeting. Two things have changed since the last one: the roadmap is a weaker explanation than it used to be, and speed on its own is no longer something to be impressed by. What's still worth knowing is whether anyone has checked the edges, and whether they can tell you what they found without changing the subject.