Software Is Becoming Disposable

For most of my career, building software was a craft, and a relatively expensive one. Businesses scoped it, specified it, estimated it, waited for IT capacity to build it and test it, and then often lived with it for a decade because replacing it was too costly to contemplate. Nearly every assumption about how organizations buy technology, from capital budgets to multi-year roadmaps to the backlog outside the IT department, grew out of that one fact.

Agile and lean software development helped streamline the process as best they could. And the advent of cloud computing and software-as-a-service (SaaS) introduced new options for businesses. But that one fact, that software remained expensive and time-consuming to create, ensured that even SaaS was costly and had its own vendor lock-in.

That fact is going away. Armed with AI, almost anyone with a clear understanding of a problem can now quickly produce working, high-quality software at a small fraction of what it used to cost. It’s not free, and it still takes skill. But it is trending toward free, and it is already cheap enough that the economics of business software, and of buying it, are starting to invert.

Summary

• Software is becoming cheap enough to treat as disposable. Generated for a specific job, used, then replaced rather than maintained for a decade.
• Data does not become disposable. It persists, it accumulates value, and it outlives every business application that touches it.
• Knowing what to build becomes the scarce skill. Once building stops being the hard part, the hardest part is understanding the business problem well enough to know what “right” looks like.
• Running the process matters more than owning the software. Someone still has to operate it, work the exceptions, and keep it current as the rules change. AI agents will take on more of that work, but someone still has to supervise them and answer for the result.
• How organizations buy software will change to match this context. Buyers will expect to see a working first version before committing, and they will increasingly buy the outcome rather than the software project.

The bottom line: when the software gets cheap and abundant, the value moves to everything around it.

Software is becoming cheap enough to throw away

Follow cheap software far enough and you arrive at disposable software. If an application takes days rather than months to produce, there’s little reason to curate it carefully for years, or to settle for a generalized SaaS product built around someone else’s process. Highly customized software can be generated for a specific purpose, used for as long as that purpose lasts, and set aside when the need changes.

Through most of the profession’s history, that would have been unthinkable, because good engineering meant building things to last. But for a growing class of problems, that may simply stop being the economical choice. The craft does not disappear altogether. But the instinct to build every piece of software as if it were permanent infrastructure will matter less, because much of it will no longer need to be permanent.

The strongest objections are real, but they point the same way

The case against disposable software deserves to be taken seriously, because most of the argument is correct. The weakest objection is that computing capacity will not keep pace with the demand this creates. But the scale of investment going into data centers makes that a short-term constraint at most. The other objections are stronger.

One is that core systems of record cannot ever become disposable. A claims platform, a general ledger, or a clinical record system persists for good reasons, and nobody should be generating a new one on demand. Another objection is that regulated software cannot simply be thrown away either: when a system makes or supports a decision that a regulator, an auditor, or a court may later examine, the record of what it did and why has to outlive it. Software that is cheap to write is not automatically cheap to own, and an application nobody understands is a liability however little it cost. Security and integration do not get cheaper at the same rate as the code.

But look at what those objections protect. Not the software, but the data, the record, the controls, and the knowledge of how the business actually works. The objections do not refute the shift; they describe where the value goes when it happens. The disposable layer is the one built around the systems of record, and as it gets cheaper, the persistent things it depends on become more important rather than less.

This has happened before. About a decade ago, Tableau disrupted business intelligence through user-led data discovery. Before it, business users accepted that analytics required significant, usually bottlenecked, IT involvement: data engineers building heavy warehouses, defining rigid canonical models, and configuring complex semantic layers before anything could be reported, much less visualized. Tableau broke that model, and the incumbent reporting tools built around it lost their grip. Yet the value of the underlying data, and of the people who cleansed, governed, and protected it, went up. The value moved; it did not disappear.

What persists is where the value moves

If software stops being the expensive, scarce part, three things take its place.

The first is data. It persists, it accumulates, and it outlives every application that touches it. An organization that understands and governs its data can point inexpensive software at it again and again. One that does not will find that faster software mostly produces faster confusion.

The second is knowing what to build. Building software used to be the bottleneck, and it was laborious, skilled work. As that work gets cheap, the bottleneck moves to understanding a business problem well enough to know what the right answer looks like, which exceptions matter, and which rules were never written down. A faster tool does not supply that knowledge.

The third is running the process. Software does not operate a business function on its own. Someone has to work the exceptions, keep up with changing rules, measure whether it is working, and be accountable for the result. AI agents will increasingly do much of that work, and do it well. But few organizations will hand a business function entirely to agents, and accountability, at least for now, still rests with people. Agents can carry out the work; people still have to direct them, supervise them, and answer for what they do. As the software approaches free, a growing share of what an organization pays for is that operation and the judgment behind it.

The business no longer has to wait to see it working

For years, a business leader with a clear operational problem and no available development capacity faced a familiar choice: join the queue for scarce internal resources, or buy a packaged product designed around someone else’s process. Part of what drove the move to SaaS, with Salesforce as the familiar example, was business units discovering they could move faster than their internal queue allowed.

Inexpensive software takes that further. A business leader no longer has to wait months to learn whether an idea works. A working first version, built against the real process, can exist in weeks.

In a regulated organization, though, speed without governance is just faster risk. Software that touches protected data still has to pass security review, vendor risk assessment, and whatever contractual protections the data requires, and it should. The point is not to get around the people responsible for those controls. It’s that seeing a working answer no longer has to wait on them. The useful question for anyone building quickly is whether what they hand over will survive that review, because a fast option that fails it was never actually fast.

Buy the outcome, and expect to see it working first

If software is becoming cheap enough to be disposable, a few things follow for how to buy it.

Expect to see a working version before you commit. When building is inexpensive, there’s less reason to choose a partner on the strength of slides, proposals, and assurances. Ask the people pitching you to show you something that runs, against a problem you actually have, even if it runs on synthetic data that mirrors yours. The ones who understand your business will find that easier than the ones who don’t.

Buy the outcome, not the software. For a large organization, the more interesting arrangement is often not licensing an application at all, but paying for a business process to be run well: the software, the domain expertise to direct it, and the operational capacity to work it, delivered together. As the software portion trends toward zero, what remains is a decision about who is best placed to run the function, and at what cost.

For a smaller organization, the change is simpler and arguably larger. Custom software that was never economical, built for exactly how the business works rather than adapted from a generic product, is now within reach. One system our team built for a small professional services firm went from kickoff to unattended production in under a month, and worked well enough that the Client has since expanded what it does. A few years ago, a firm that size would not have commissioned custom software at all.

When the software gets cheap, the value moves

The organizations that do well through this shift will be the ones that stop treating software as the scarce asset. They will govern their data as the thing that lasts, value the people who understand the work, and buy the running of a process rather than the code beneath it. Software will increasingly be the least expensive part of the answer. Knowing what it should do, and making sure it keeps doing it, will not.