The data that says something really has moved
The best-documented number comes from August 2026, from 97 countries and 1,719 respondents:
"Nearly a third of respondents (32 percent) report that their organisation decided not to purchase at least one software product or feature because it was able to build the functionality in-house with agentic coding tools."
Technology and healthcare lead, followed by professional services and energy. The same survey has another number that has not moved, though: only 37% of organisations can report a demonstrable, AI-attributable impact on their operating results — exactly as many as a year earlier. So building got cheaper; the return did not get better.
Another survey, of 817 developers, shows the same pattern:
- 35% of respondents have already replaced at least one purchased tool with something built in-house;
- 78% plan more in-house tools in 2026;
- the pressure to replace is highest where integration is thinnest: by category, workflow automation 35% and internal admin tools 33% — a different breakdown, not the 35% above;
- 60% built a tool outside IT oversight in the past year — the reasons: speed 31%, an unmet need 25%, slow IT 18%;
- and a third 35%, unrelated to the other two: that share of respondents has no AI productivity metric whatsoever.
(The second survey comes from a tool vendor, so from an interested party.)
That last figure says the most. One company in three makes a build-or-buy decision without measuring how much AI actually helped.
What came down, and what did not
What came down: the cost of getting the first version built. We cannot put a currency figure on that, but the two numbers above show that decision-makers can feel it.
What did not come down — and there is measurement for this:
| Cost item | What gets measured |
|---|---|
| Security | 45% of generated code samples fail a security test; for one large enterprise language the failure rate is 72% |
| Maintainability | the share of refactoring fell from 21% to 3.8%, duplication grew by 81% (623 million code changes) |
| Delivery stability | AI use correlates negatively with it |
| Infrastructure security | the vulnerability density of generated configuration is 3.2–3.9 times the human one |
| Running it | at ten thousand requests a month, inference costs $15–350 depending on model tier |
| Incident handling | median time to resolve your own failure 96 minutes, a vendor's 247 minutes |
That last row is interesting because it argues against the vendor: you fix your own failure faster. Except that your on-call rota does not staff itself.
And there is one thing worth saying out loud separately: building a prototype and maintaining an existing system are not the same job. In a controlled experiment on a mature, large codebase, AI slowed experienced developers down by 19% — while they felt a 20% speed-up. That is exactly the heart of the build-or-buy decision: the first month got cheap, the third year did not.
The line the classic calculation leaves out: who is the provider
This is the most important and the least known part of this post.
Under the definitions in the EU AI Act:
- A provider is whoever develops an AI system, or has one developed, and places it on the market or puts it into service under their own name.
- A deployer is whoever uses an AI system under their own authority.
- And the decisive definition: "putting into service" also covers making a system available for your own use.
What follows is that anyone who builds an AI system for their own company is a provider AND a deployer at the same time — with both sets of obligations. Anyone who buys the same thing is only a deployer, with substantially fewer obligations.
And there is a passage where the "we only wrap the model" argument collapses. Under the Act, a distributor, importer, deployer or other third party becomes a provider in respect of a high-risk system if
- they put their own name or trademark on it;
- they make a substantial modification that affects compliance;
- or they change the intended purpose — including that of a general-purpose AI system — such that it becomes high-risk.
Let us keep this in proportion, so it does not turn into scaremongering. The full set of obligations applies to high-risk systems, and most internal tools are not that.
But. Among the high-risk categories sits employment: recruitment, promotion, task allocation, worker monitoring. Which is precisely the area where companies most often build something internally.
And one clarification on dates, because many sources are out of date: in the summer of 2026 the deadline for high-risk system obligations was postponed to December 2027. Anyone still naming August 2026 for those obligations is working from an old source. The postponement covers only them: general application and the transparency rules have been in force since August 2026, and the AI literacy obligation since February 2025.
(The Act applies directly in every member state; it does not need to be transposed.)
A worked example
Take a thirty-person company looking for an internal approval and workflow tool. The version you can buy: thirty seats at $25 per person per month — $9,000 a year.
| Item | Year 1 | Year 2 onward / yr |
|---|---|---|
| Development: 120 hours × $60 | 7,200 | — |
| Maintenance (20% of development) | — | 1,440 |
| Model usage: 10,000 requests a month, mid tier | 1,680 | 1,680 |
| Hosting, database, monitoring | 600 | 600 |
| Security review | 2,000 | 1,000 |
| Own build, total | 11,480 | 4,720 |
| Bought | 9,000 | 9,000 |
(Own calculation with assumed parameters. Only the model prices and the security and maintainability ratios are verified — the hours, the hourly rate and the hosting cost are estimates.)
In year one, building it yourself is more expensive. From year two it is cheaper. The payback lands somewhere around the nineteenth month — assuming the tool does not change.
And that is exactly where the trap is. By the measurements above, the maintenance line does not get smaller, it gets bigger: refactoring collapses, duplication grows. Anyone counting on a nineteen-month payback has typically written in the most optimistic maintenance line.
The point of the table is not to give you the answer, it is to show you where the lines are that the classic calculation leaves out: running the model, the security review, the compliance role — and maintenance, which the AI era has not made any smaller either.
One line the table above does not contain: public money. In several member states part of the purchased software and of the consultancy is covered by a non-repayable grant — and that tips the buy-or-build balance directly, because what usually gets funded is the purchase, not the in-house build. Open the one that applies to you:
Hungary — no standalone AI grant; AI rides along with a website programme
There is no standalone AI adoption grant for SMEs as of September 2026. What there was: the second round of the "every business should have its own website" programme opened on 3 February 2026 with a budget of 1.2 billion forint, offering vouchers between 400,000 and 2 million forint at 100% intensity — and this is where AI appeared, as a 500,000-forint "AI package".
That budget ran out in four days: the call was closed on 6 February 2026 for exhaustion of funds, with over a thousand applications submitted.
The other live option is the SME digitalisation grant, with a budget of 30 billion forint, between 3 and 12 million forint per applicant, at up to 90% intensity, for micro and small companies outside Budapest, between 31 March and 30 June 2026. Artificial intelligence, however, is not named among the eligible activities — hardware, software, IT security and training are.
Spain — there is a named AI consultancy voucher, it is just closed
Spain has a state programme in which AI consultancy is a separate, named product: under the Kit Consulting voucher scheme an SME gets 12,000 euros at 10–49 employees, 18,000 at 50–99 and 24,000 at 100–249, and within that the "AI advisory service" is 6,000 euros in all three bands. It is not only analysis: the specification includes the actual implementation of one use case tailored to the business.
Its sibling programme, Kit Digital, first took AI tools into its catalogue at the end of 2024, with vouchers of 25,000 euros at 50–99 employees and 29,000 at 100–249.
The practical position, though, is that neither programme is open in September 2026: the Kit Consulting call closed in February 2025, the last regular Kit Digital calls in October 2025, and no official document sets a new deadline. The legal framework is alive, the tap is shut.
What to take from it: if you are a Spanish SME leaning towards buying, the reopening of the voucher schemes can be the single largest line in the calculation — 6,000 euros of consultancy is roughly the entire first-year cost of a smaller in-house build.
The decision rule
BUILD IT IF
it is an internal tool with few integrations
the process is unique TO YOU (so no good product exists)
nobody loses money when it dies
and someone will still maintain it THREE YEARS from now
BUY IT IF
someone else's data, money or compliance is involved
it needs many integrations
it needs a certification (with SaaS that is a product
feature, on your own you start from zero)
it touches an EMPLOYMENT decision -> the regulatory
burden is an order of magnitude bigger here
IN BOTH CASES
write down IN ADVANCE what you will measure. A third of
companies have no AI productivity metric at all - and
they make this same decision.
Common misconceptions
- "Building it with AI is always cheaper." The first version, yes. In the worked example, year one is still more expensive than the bought version.
- "We only wrap the model, we are not a manufacturer." If you modify the intended purpose so that it becomes high-risk, the Act says you become a provider.
- "An internal tool is not regulated." Most are not. But a tool supporting an employment decision is in the high-risk category — and that is exactly the kind people build internally.
- "Maintenance will get cheaper with AI." In a controlled experiment on a mature codebase, AI slowed people down by 19%. The share of refactoring fell from 21% to 3.8% over four years.
- "More and more people are building, so it must be the right direction." In the same survey, the demonstrable bottom-line impact stands at 37%, unchanged for a year.
What to take away
One line of the build-or-buy calculation really has come down: the price of the first version. The rest stayed — and two lines arrived that you never used to write in: running the model and the regulatory role. Whoever builds for themselves is, under the Act, a provider and a deployer at once; whoever buys is only the latter.
And the best practical filter is not cost but a question: will there be someone to maintain this in three years?
Where the fast prototype stops is mapped out in the 70% wall post, in detail; the question of who answers for it belongs to the vibe coding reality check post, with the boundaries.