Software has always been expensive to build, which is why businesses built little of it and kept what they built. That assumption is now being retired in public. The advice arriving with it is aimed at corporate IT departments; the part that matters to everyone else is quieter, and it is not about software at all.
01 — What happened
On 20 October 2026, at its IT Symposium/Xpo in Orlando, Gartner published its top ten strategic technology trends for 2027. One of them is disposable applications, which Gartner defines as “purpose-built software applications designed to be intentionally retired once their specific business purpose has been fulfilled”.
The scale of the claim is the interesting part. Gartner’s prediction, presented at the same event, is that by 2029 80% of new applications will be designed for use lasting under a year. Gene Alvarez, a distinguished vice-president analyst at Gartner, put the consequence plainly: “Transitioning to disposable applications fundamentally alters how software is bought, designed and budgeted for.”
This is a forecast, not an event. What makes it plausible is an event. On 25 September 2026 Microsoft rebuilt its Copilot application around three areas, one of which is Code — a capability that, in Microsoft’s own words, “enables users to build applications and automations using natural language” and is “designed to enable non-developers to securely create their own solutions within their organization’s environment”. It runs on the same technology as GitHub Copilot and is rolling out through Microsoft’s Frontier early-access programme. The person described there is not a developer. It is someone in operations who needs a tracker by Thursday.
Gartner’s list contains the matching constraint. AI coding agent harness exists because, as the trend description has it, “without a dedicated harness, developers must spend time manually verifying machine output”. Network World’s summary of the briefing stated it directly: machines are producing software faster than teams can audit it, and manual reviews are becoming the primary bottleneck.
Both halves of the story are on the same list. Making software got cheap. Checking it did not.
02 — Why it matters
The instinct is to file this under enterprise IT governance and move on. That is a mistake, because the barrier protecting most businesses from software sprawl was never a policy. It was the price.
When an internal tool costs real money and a developer’s time, it gets a sponsor, a specification and an argument about whether it is worth it. Few survive that. When it costs an afternoon and a prompt, none of that happens, because none of it is warranted by the cost. The output is not a few considered applications but many unconsidered ones, each sensible on its own.
The exposure is specific, and it is not security. An application built to live six weeks quietly becomes the only place a piece of business truth lives. The quote tracker built for one unusual project becomes where quotes are kept. The onboarding checklist becomes the record of what was promised. Nobody decided this; the tool was convenient and nothing else was.
At that point the application is not disposable. It is load-bearing, undocumented and owned by one person. Reporting from the Gartner event put it from the other side: most organisations have no lifecycle plan for software meant to expire.
03 — The economics
Software has three cost lines: building it, running it, and getting rid of it. AI collapsed the first and left the others untouched. Retirement got worse, because there is now far more to retire.
Take an illustrative example: a forty-person services business whose operations lead builds six small tools over a year — a quote tracker, an onboarding checklist, a jobs dashboard, two report generators and a stock sheet. Assume a day each. Build cost is effectively nothing, and the first month’s value is real.
The cost arrives elsewhere. Each tool needs customer or job data, so each takes a copy. By month nine, two are in daily use, three are abandoned but still running, and one holds the only record of what was agreed with a set of clients. Nobody can say which of the six writes anywhere that matters.
The number that grows is not the count of applications. It is the number of places the same fact lives. Every additional copy creates reconciliation work: when two systems disagree about a customer’s address, a job’s status or what was quoted, someone must decide which is right, case by case, indefinitely. The mechanism is the one behind what disconnected systems actually cost. Cheap software does not change it. It raises the rate at which you generate it.
There is a second cost, and research has put a name on it. DORA, Google Cloud’s software delivery research programme, reported in March 2026 that time saved during initial code generation “is often re-allocated to verification overhead” — saved writing, re-spent auditing. In the same work, 30% of developers reported little to no trust in AI-generated code. Developers at least review each other. When a non-developer builds a tool for their own team, there is usually no reviewer at all. The verification cost does not disappear; it goes unpaid, and the bill arrives as a wrong number in a report nobody questioned.
Which gives the test. Disposability is free when an application holds no record, and expensive when it does. Everything else about this trend follows from that line.
04 — What businesses should do
Before anyone builds anything, answer one question: where does this write? A tool that reads from systems you already run and writes nothing durable can be deleted on a Friday with no consequence. Build those freely — that is the genuine opportunity. A tool that becomes the only home of a customer detail, a price, a commitment or a status is not disposable, whatever was intended. Those need an owner and a place in your real systems.
Write down where business truth currently lives. Customers, enquiries, quotes, jobs, invoices — one line each, naming the authoritative system. If a category has more than one authoritative home, or none, you already have the problem this trend will accelerate. Fix that before you hand everyone a tool factory.
Put an expiry date on anything built this way, at the moment it is built. A name, a date, and one sentence on what breaks if it vanishes then. Two minutes, and it is the only governance most businesses need. Review the list quarterly: anything that has survived two reviews and is still in daily use has stopped being disposable, and should be rebuilt properly or absorbed into something maintained.
If you employ more than about twenty people, assume this has already started. It has been happening in spreadsheet macros, shared documents and low-code tools for years; the new tooling only makes it faster. The question is whether anyone is counting. Most businesses that have outgrown their spreadsheets got there one reasonable shortcut at a time.
Draw one hard line and keep it. Nothing a customer sees, and nothing holding money or a legal commitment, gets built disposable. The failure mode is not an outage; it is a wrong figure nobody catches because the thing that produced it looked like a small internal tool. And do not buy a governance platform for six applications — at your size, a list in a shared document solves it.
05 — Where technology fits
For most businesses reading this, there is nothing new to buy. That is the honest answer.
What this trend requires is a decision, not a product: what is your system of record for each kind of business fact? Often it is something you already pay for and under-use. A CRM that holds customers, enquiries and jobs properly is what makes everything built around it genuinely throwaway, because the valuable data never lived in the throwaway part. That is the argument for treating systems as a connected structure rather than a collection of tools.
Where new work earns its place, it is usually an integration rather than an application: the quick-built tool reads from and writes to the record instead of keeping its own copy. That is smaller than building the tool, and it decides whether the tool is safe to delete.
A custom web application is justified at the other end: when something built quickly has proven over months of real use that it must persist. Permanence should be earned by survival, not assumed at the start — the same discipline that governs whether to build a mobile application at all.
You almost certainly do not need an AI governance layer. You need a list, an owner per item, and a rule about what writes where.
06 — RevenueStack’s take
Our view: “disposable” is not a property of software. It is a property of where the data sits — and the trend has been announced as a change in how software is bought when it is really a change in how data gets scattered.
The useful reading is the opposite of the obvious one. Cheap, throwaway software does not reduce the value of a system of record. The record is the only thing that converts a disposable application from a liability into a genuinely free experiment. Build on a clean record and you can throw away as much as you like. Build without one and every cheap tool is another version of the truth, generated at the new, lower price.
Which is the uncomfortable part. The businesses best placed for an era of disposable software are those that invested in the undisposable layer first. The rest will not get software abundance. They will get fragmentation, faster, and will not notice until two reports disagree and nobody can say which to believe.
Sources
- Gartner's top tech trends for 2027 expand—and constrain—AI capabilities — Network World, 2026-10-20
- LIVE From Gartner: 10 Bold Predictions for CIOs in 2027 and Beyond — The National CIO Review, 2026-10-21
- These are Gartner's top strategic technology trends for 2027 — IT-Online, 2026-10-22
- New Microsoft Copilot brings Home, Code and Autopilot together — Microsoft, 2026-09-25
- Balancing the tensions of AI-assisted development — DORA, Google Cloud, 2026-03-10
