Roughly 32 percent of organisations report skipping at least one software purchase this year because they could build the equivalent internally using agentic coding tools. That figure has been passed around as evidence that buying software is finished, which it is not.
What it actually tells you is narrower and more useful. A specific class of purchase became uneconomic to make, the boundary moved, and the businesses that benefited had something in common that has nothing to do with how good the tools are.
What moved and what did not
The cost of producing working code fell substantially. That is real and it is not the whole equation, because writing the code was rarely the expensive part of internal software.
The expensive parts were deciding what to build, discovering the requirements nobody mentioned, and then owning the result for years. None of those got cheaper. An agent can produce a working reporting tool in an afternoon and cannot tell you that finance needs the figures on a Tuesday because that is when the board pack goes out.
So the boundary moved for work where the requirements are already known and the scope is genuinely closed. A tool that moves records between two systems you already run. A dashboard over a database you already have. An internal form that replaces a spreadsheet everyone already agrees on. These were bought because building them was not worth an engineer's month, and they are no longer worth an engineer's month.
The boundary did not move for anything where the requirements are contested, the domain is unfamiliar, or the consequence of being wrong is regulatory.
Read More - A Dollar Per Automated Resolution: What Outcome Billing Costs the Buyer
The second year is the one to model
Here is the question that separates a good build decision from an expensive one, and it is almost never asked during the decision.
Who maintains this in eighteen months, when the person who built it has moved to another team, the API it depends on has changed twice, and nobody has read the code since it was written.
Purchased software carries that obligation for you. The vendor tracks the API change, ships the fix, and handles the security patch you never heard about. That is a meaningful part of what a subscription buys, and it is invisible precisely because it works.
An internal build transfers all of it to you permanently. Not as a project with an end date, but as a small recurring tax on your engineering capacity that grows as the tool accumulates users who depend on it. Three such tools is manageable. Fifteen built over two years because each one was cheap is how teams end up unable to ship anything new.
We see the second year underestimated more consistently than any other number in these decisions. The build lands roughly on budget and the maintenance is absorbed by whoever happens to be free, which keeps it invisible until that person leaves.
Code you did not write is still code you own
There is a specific version of this risk when the code was generated rather than written, and it is worth naming plainly.
A developer who writes something understands the decisions inside it. A developer who accepted a generated implementation may not, particularly the parts that looked reasonable and were never examined closely. That gap does not matter while the software works. It matters enormously at two in the morning when it does not.
The practical control is unglamorous: whoever ships it must be able to explain it. Not to have written every line, but to be able to say what it does, why it does it that way, and where it would break. If nobody on the team can, you have not built software, you have acquired an artefact.
Review, tests, and documentation matter more for generated code rather than less, which is the opposite of how it usually gets treated.
When we take over a system somebody else assembled, the first month is almost never feature work. It is establishing what the thing does, and that cost belonged to the original decision even though nobody recorded it there.
The purchases most exposed right now
If you sell software, this is where the pressure lands, and it is fairly predictable.
Thin tooling with no proprietary data. A pleasant interface over a database, priced per seat, sold to any industry. That description now matches something a competent team can assemble, and buyers have noticed.
Point solutions that solve one narrow problem. These were always vulnerable to bundling and are now also vulnerable to internal replacement, because a narrow problem is exactly the kind with closed requirements.
What holds up is data you cannot reproduce, workflows spanning organisations, and anything where being wrong has a compliance cost. We looked at the same shift through the valuation lens in what agents did to software valuations, and the pattern is consistent from both directions.
Read More - Your App Quietly Stops Reaching New Phones: The Android 16 Target API Deadline
A decision framework that survives contact
Three questions, answered honestly, get most teams to the right answer.
Are the requirements genuinely settled, or does settling them require conversations nobody has had. If the second, the build estimate is fiction, because scope discovery is the expensive part and it has not started.
Is this differentiating or is it plumbing. Building something that makes you distinctive is usually worth owning. Building a payroll system is not, regardless of how cheap it has become, because you will maintain it forever against regulations that change annually.
Who owns it in two years, by name. If the answer is a shrug or a team rather than a person, the maintenance will not happen and you are building something that will quietly rot into a dependency nobody understands.
The other question that decides this is whether anyone will be able to maintain what you build, which we came back to in what happens when nobody understands the system.
Teams that answer these and still choose to build usually should. Our custom software development work is frequently exactly this: something a client could now assemble, built properly, because the difference between working and maintainable is where the cost actually lives.
Frequently Asked Questions
Does this mean we should stop buying software?
No. It means the shortlist has a third column now, and that column wins more often than it used to for closed scope internal tooling. For anything involving proprietary data, regulated processes or genuine domain complexity, buying remains the better decision and the reasoning has not changed.
How do we estimate a build now that generation is fast?
Estimate the parts that did not get faster. Requirements gathering, integration with systems that behave badly, testing, deployment, and the first six months of fixes after real users arrive. Generation compresses one phase of several, so a build that used to take six weeks might now take four rather than four days.
What is the real ongoing cost of an internal tool?
Budget a few days per tool per quarter as a baseline, more if it touches external APIs or handles payments. That covers dependency updates, breakage from upstream changes, and small requests from users. It sounds trivial until you have a dozen tools, at which point it is a permanent part of a person's job.
Our engineers say they can build it in a week. Should we believe them?
Believe the week and ask what happens in month nine. Engineers are usually right about the build and rarely asked about the maintenance, because the question is not put to them. Add the second question to the conversation and the estimate becomes considerably more useful.
Is generated code safe to put in production?
It is as safe as your review process. The risk is not that a machine wrote it, it is that nobody examined it closely because it looked finished. Apply the standards you would apply to a contractor's first pull request, and the code is fine. Skip that, and you have introduced something nobody can support.
What if we build it and later want to buy?
That path exists and is more common than people expect. Building first teaches you what you actually need, which makes the eventual purchase decision far better informed. Keep the data model clean and exportable so the migration is possible, and treat the internal version as a working specification rather than a permanent commitment.
How do we stop internal tools multiplying unchecked?
Require a named owner and a retirement date at the point of building, not afterwards. Most internal tools that become a burden were never intended to last; they simply had nobody responsible for deciding when they should stop. A named owner and a review date costs nothing and prevents most of it.
Talk to our team if you are weighing a build against a purchase and want the second year modelled as well as the first.