Should we build internal tools with AI instead of buying SaaS?

It depends almost entirely on the size of the licence you are replacing. A $200 a month product almost never justifies it, because you are trading a small predictable cost for an unbounded maintenance obligation. A multi-million licence for a platform you are already bending out of shape with integration work frequently does justify it, because at that scale you are already partway to a bespoke system.

Why do AI-built internal tools tend to fail after about a month?

Building stays easy for long enough to convince you the whole project is tractable, then stops. You lose an afternoon failing to debug something, and your options are another model that will not help or reading twenty thousand unfamiliar lines yourself. A month is also roughly when maintaining it stops being enjoyable, which is when it gets abandoned along with the unaccounted cost of producing it.

How do you tell whether internal tool building is hurting your roadmap?

Ask whether the work is attached to a named objective, who maintains it in six months by name, what it cost at your enterprise rate rather than the consumer sticker price, and what it replaces. Activity metrics will not warn you: commits, pull requests, velocity, and cycle time all reward self-contained work with no stakeholders, which is exactly what an unsanctioned internal tool is.

Is AI going to replace enterprise SaaS?

The displacement question has moved from an engineering in-joke to a mainstream market concern, with 'SaaSpocalypse' now a named fear about capable models eroding per-seat subscription demand. Salesforce has been among the weakest large-cap SaaS names of 2026 and SAP fell sharply on cloud backlog concerns, though some of the sector pressure reflects AI capital spending rather than displacement.

Blog

Everyone Is Building Internal Tools Again. Most of Them Die in a Month.

Jirka Bachel and Peter MalinaAugust 7, 20267 min read

Start with the part nobody puts in the board deck: coding agents are addictive.

If you enjoyed Lego, or spent a weekend of your childhood on SimCity, you already know the feeling. There is a genuine dopamine hit when the agent comes back with the thing finished. We feel it too. That is not a criticism of anyone, it is the mechanism, and you cannot manage a behaviour you will not name.

What it produces, across every company we talk to, is the same thing at once: everybody is building internal tools again.

An agent gives every engineer a team and takes away their product manager

The clearest way we have found to describe what happens is this. An agent turns an engineer into an engineering manager overnight. They now have a team of workers who will do what they are told, quickly, without complaint.

What they do not have is a product manager. Nobody is asking whether this is on the roadmap, whether a customer wanted it, or what it displaces. So they build the thing they always wanted to build, which is usually the thing that annoys them personally rather than the thing that is costing the company money.

The output is remarkably consistent. Internal Jira integrations, most of all. We have lost count of how many have been built inside companies this year, frequently several inside the same company by people who did not know about each other. Then dashboards, small CRMs, refactors nobody asked for, optimisations of things that were not slow.

Underneath it sits a pricing blind spot. Most engineers reason about cost from the consumer sticker price of their tool, because that is the number they have seen. The enterprise cost per seat is a different figure entirely, and agent runs against a large codebase are a different figure again. So the side project feels free. Nobody is being reckless. They simply do not have the number.

The month

Here is the pattern, and we include ourselves in it.

You build because building is easy. It stays easy for a surprisingly long time, which is the trap, because the ease is what convinces you the whole thing is tractable. Then one afternoon it stops. You spend three hours failing to debug something and you cannot work out why it still does not work.

At that point you have two options. Point another model at it, which will not help, because the reason the first one is stuck is not a lack of models. Or read twenty thousand lines of code you have never read, which you will not do, because you did not sign up for that.

So you buy the thing. The twenty dollar a month product you could have bought before any of this started, and which you skipped because you wanted to build it yourself.

A month is roughly how long this takes, and a month is also the point where maintaining it stops being fun. That is when it quietly goes in the bin, along with whatever it cost to produce, which nobody ever totals up.

The mirror test

The most useful version of this argument we have run into came from the other side of a table.

A while ago the CTO of a well known customer support SaaS told us, cheerfully, that he thought he could build our product in a week. We told him we thought the same about his.

Then we asked what he tells his own customers when they announce they are going to build customer support software in a week. He had the answer immediately and it was several minutes long: impossible, because of this, and this, and this, and the twelve things you have not thought about yet.

Both of us were right about ourselves and wrong about each other, in exactly the same way and for exactly the same reason. What you are missing when you look at somebody else’s product is not capability. It is specificity. You do not know what the thing actually has to do, because you have not spent four years being told by customers what it has to do.

That is the part you cannot prompt for. You have all the speed in the world and no idea what to point it at, which is a description of most vibe-coded internal software.

When building internally is the right answer

Now the other side, because it is real and it is getting more real every quarter.

The economics change with the size of the licence. Paying a few thousand a month for something is a completely different decision from paying tens of millions a year, and the vendors charging the second number did not get where they are by selling ten dollar seats. At that scale, the build option stops being a hobby and becomes a serious line of argument.

There is a second reason it works at that end of the market: enterprises are usually bending those systems badly out of shape already. Once you are paying for a platform and then paying again for the integration work that makes it fit, you are partway to a bespoke system with worse ergonomics and a licence attached.

The market has priced some of this in. “SaaSpocalypse” is now a named fear on the street, the worry that increasingly capable models erode demand for traditional per-seat subscriptions. Salesforce has been one of the weakest large-cap SaaS names of 2026, down around 35% year to date, and SAP fell sharply on cloud backlog and forecast concerns [1][2]. Not all of that is this argument, and some of the sector pressure is about AI capital spending rather than displacement. But the displacement question is now a mainstream one rather than an engineering in-joke.

A horizontal scale of annual licence spend. At the low end, buy. At the high end, building internally can pencil. The transition between them is deliberately unmarked. — *Schematic, deliberately. The transition band has no number on it because the crossover depends on how much integration work you are already paying for on top of the licence.*

Four questions that separate the two cases

The difference between a defensible build and a project that dies in a month is not technical, and you can usually tell before you start.

Is it on the roadmap, or is it a side effect of an interesting afternoon? The honest answer is usually available immediately.
Who maintains this in six months, by name? If the answer is the person who built it, and they built it because it was fun, you have your answer.
What did it cost at your enterprise rate, not the consumer sticker? Most people have never run this number for an internal tool. It is frequently the number that ends the discussion.
What are you replacing? A $200 a month SaaS product almost never justifies it. A multi-million licence for a platform you are already bending out of shape frequently does.

Three of four pointing the wrong way and you are building something that will be deleted before the next quarter closes.

Why your metrics will not warn you

The thing that makes this expensive rather than merely wasteful is that every instrument most companies have will applaud it while it happens.

Commits go up. Pull requests go up. The person doing it looks like one of your strongest engineers, because by every activity measure available they are. Velocity rewards them. Cycle time rewards them, because self-contained work with no stakeholders moves fast by definition.

Five dashboard tiles. Commits, pull requests and velocity are up, cycle time is down, and roadmap alignment is none. — *An unsanctioned internal tool moves every one of these in the direction you want, except the one nobody has on the dashboard.*

This is the same pattern we see across our customer data, where the highest performers in almost every instance are the people contributing least to the roadmap. It is easy to look fast when nobody sends your work back. Everyone building things customers asked for is two to three times slower, because they have to listen.

The only way this becomes visible is if you score what was delivered and then ask what share of it attached to a named objective. That is why we measure output per commit as ETV and split it by roadmap alignment rather than counting activity. Unattached work is not a rounding error. In most orgs we look at, it is a large fraction of the total, and it is invisible to everything else on the dashboard.

The question was never whether your team can build it. Since about a year ago the answer to that has been yes, for almost anything, faster than you expect. The question is whether the thing they built was the thing the company needed, and whether anybody will still be maintaining it once the novelty wears off.

References

[1] Reuters via Yahoo Finance, “US software stocks slump as AI disruption fears take over,” 2026. [Online]. Available: https://finance.yahoo.com/news/us-software-stocks-slide-sap-151029472.html

[2] 24/7 Wall St., “Oracle Plunges 10% After Earnings, Salesforce Slips Near 52-Week Lows as Cloud Stocks Slide,” June 2026. [Online]. Available: https://247wallst.com/investing/2026/06/11/oracle-plunges-10-after-earnings-salesforce-slips-near-52-week-lows-as-cloud-stocks-slide/

Frequently asked questions

Should we build internal tools with AI instead of buying SaaS?: It depends almost entirely on the size of the licence you are replacing. A $200 a month product almost never justifies it, because you are trading a small predictable cost for an unbounded maintenance obligation. A multi-million licence for a platform you are already bending out of shape with integration work frequently does justify it, because at that scale you are already partway to a bespoke system.
Why do AI-built internal tools tend to fail after about a month?: Building stays easy for long enough to convince you the whole project is tractable, then stops. You lose an afternoon failing to debug something, and your options are another model that will not help or reading twenty thousand unfamiliar lines yourself. A month is also roughly when maintaining it stops being enjoyable, which is when it gets abandoned along with the unaccounted cost of producing it.
How do you tell whether internal tool building is hurting your roadmap?: Ask whether the work is attached to a named objective, who maintains it in six months by name, what it cost at your enterprise rate rather than the consumer sticker price, and what it replaces. Activity metrics will not warn you: commits, pull requests, velocity, and cycle time all reward self-contained work with no stakeholders, which is exactly what an unsanctioned internal tool is.
Is AI going to replace enterprise SaaS?: The displacement question has moved from an engineering in-joke to a mainstream market concern, with 'SaaSpocalypse' now a named fear about capable models eroding per-seat subscription demand. Salesforce has been among the weakest large-cap SaaS names of 2026 and SAP fell sharply on cloud backlog concerns, though some of the sector pressure reflects AI capital spending rather than displacement.