Terran Labs
Back to resources

The End of the Button: Why Software Is Moving From Renting Tools to Selling Outcomes

20 minadmin9/23/2026
The End of the Button: Why Software Is Moving From Renting Tools to Selling Outcomes

For roughly two decades, the pitch behind cloud software was almost impossibly clean: stop buying boxes, stop maintaining servers, and let someone else worry about uptime. Software as a Service was not merely a pricing model — it was an emotional release. Companies that had once spent six-figure sums on hardware, licenses, and the people to keep them alive suddenly rented capability by the seat, by the month, for a fraction of the pain. That shift genuinely deserved the word revolution.

Then something strange happened. The revolution succeeded so completely that it turned on the people it had freed. A typical mid-sized company today runs somewhere between eighty and three hundred SaaS applications. Each one arrives with its own onboarding flow, its own notification settings, its own dashboard, its own vocabulary for the same customer, the same invoice, the same deal. The average knowledge worker now spends a large fraction of the day not doing work, but tending the tools that are supposed to do the work: exporting, importing, reconciling, copy-pasting between browser tabs, and clicking buttons that exist mostly because a human is expected to be present to click them.

That is the paradox of the late 2020s. SaaS removed the burden of hardware and replaced it with the burden of attention. And attention, unlike a server, cannot be bought back at a discount.

The Dashboard We Mistook for Progress

The strongest asset a SaaS company ever had was not its database schema or its uptime statistics. It was usability. Interface design was the moat: a beautiful dashboard, a forgiving form, an onboarding tour that turned a confused buyer into a confident user. Vendors competed on how little training a new employee needed, how few clicks it took to complete a task. Entire product disciplines — UX research, interaction design, usability testing — grew up around the idea that the human being in front of the screen was the primary consumer of the software’s value.

AI agents have quietly dismantled that assumption. When a model can look at a screen, understand what is on it, and act on it the way a person would, the visual layer stops being a competitive advantage and starts being an obstacle. An agent does not admire a color palette. It does not appreciate the thoughtful empty state, the gentle tooltip, the carefully worded error message. To an autonomous system, a friendly form field is simply a detour — a bypass to route around on the way to the same API endpoint the button would eventually call.

This is what it means to say that UI and UX have lost their premium. It is not that design no longer matters to people; it is that the paying logic of the market has moved. The interface was the reason to choose one vendor over another when a human had to live inside the tool all day. When software becomes something that other software operates, the interface is no longer where the money is. The value migrates downward, into the data model, the integrations, the reliability of the workflow, and the quality of the result.

And once that migration happens, the seat-based license becomes an artifact. You do not need a seat if nobody is sitting.

When Interfaces Stop Being the Product

The technical precondition for all of this is the ability of machines to interact with systems directly rather than through a person. The arrival of computer-use capabilities — models that can perceive a graphical interface and execute sequences of actions inside it — crossed that threshold, but the deeper shift is architectural. Modern software is increasingly designed API-first: the interface is a courtesy layer for humans, while the true product surface is a set of endpoints that anything with credentials can call.

The contrast with earlier design philosophy is sharper than it first appears. Traditional applications were reactive. They sat still and waited for a human to press something. Every state change began with a hand on a mouse. Contemporary systems, by contrast, are built around loops: observe the environment, decide what matters, act, then observe the result of the action and adjust. That loop is what people mean when they talk about agentic workflows. It is not a single instruction and it is not a script; it is a continuous cycle of perception and judgment that can span several systems at once.

The practical consequence is that the unit of automation changes. A decade ago, automation meant a rigid connector that moved a record from one database to another on a schedule. Today, an agent can read an unusual request in a messaging thread, decide which three systems need to be consulted, retrieve the data, post a draft response, detect that the draft misunderstands a nuance, revise it, and log the interaction. Nobody configured that exact path in advance. The agent composed it.

Once the composition step becomes reliable, the interesting question is no longer which tools a company owns. It is who is conducting.

Three Models, Three Kinds of Responsibility

The vocabulary that has emerged in Silicon Valley to describe this transition is worth taking seriously, because it separates three genuinely different economic contracts rather than three marketing labels. The underlying idea sometimes appears as Service-as-Software, and sometimes as hiring software: instead of using a tool, you employ a capability, the way you would hire a junior colleague.

In the first model, the customer buys access. In the second, the customer buys work. In the third, the customer buys the outcome itself. Those differences cascade into who holds the risk, how the invoice is calculated, and what a human being is actually for.

  • Software as a Service — the keyword is access and ownership of features. You pay per seat or per license, usually a flat subscription. The human is an operator, pressing the buttons the interface provides. Risk sits with the buyer, because the buyer carries the responsibility of using the tool competently. Typical examples are the classic CRM, the accounting package, the project tracker.
  • Work as a Service — the keyword is hiring software to perform the task. You pay for the process itself: compute consumed, API calls executed, units of work completed. The human shifts into collaboration, giving feedback and steering quality. Risk is shared, because the vendor is answerable for how the work is carried out. Examples include image generation services and the various AI copilots that sit beside a professional and do part of their job.
  • Result as a Service — the keyword is outcome-based delivery. You pay only when the result arrives: per resolution, per booked meeting, per closed ticket, per verified financial statement. The human becomes designer and evaluator, commanding the system as a whole. Risk moves decisively to the vendor, who now owns the promise of the outcome. The most cited example is customer support priced per resolved conversation, in the region of a dollar per resolution.

The third row is the one that frightens executives and excites founders in equal measure, because it inverts the commercial relationship. When you sell a result, the buyer’s failure to realize value stops being the buyer’s private problem. It becomes your revenue problem. That is uncomfortable, and it is also precisely why outcome pricing wins trust so quickly when it works.

Work as a Service and the Junior Designer Metaphor

Not every domain collapses neatly into Result as a Service, and this is where the middle model earns its place. The useful framing comes from Dharmesh Shah, who describes Work as a Service as either a stepping stone toward outcome pricing or a permanent complement to it.

His metaphor is a junior designer. Ask an AI to illustrate a book and something subtle happens: the definition of finished becomes subjective. Is the eleventh variation better than the tenth? Is the mood right? Has the character’s expression drifted away from what the author felt but never managed to articulate? In creative work, the answer is not knowable in advance, and demanding a fixed result actually damages quality, because it forces premature closure. What has value here is the rally itself — ten rounds, a hundred rounds, each one slightly better because a human stayed in the loop, reacted, and pushed.

When the process is the product, paying for Work makes more sense than paying for a promised Result. It aligns the incentive with iteration rather than with a rushed finish line, and it keeps human taste in the middle of the loop where it can actually shape the output. Design, writing, brand strategy, and product discovery all behave this way. In these fields, a vendor who guarantees a fixed deliverable will almost always deliver something mediocre on time.

This diversification of models has been accelerated by the fact that agents no longer stop at single instructions. Beyond the basic create-read-update-delete operations, they now move autonomously across multiple systems, holding context, resolving ambiguity, and coordinating with other agents. As that coordination improves, the boundary between buying work and buying a result becomes a commercial choice rather than a technical limit.

Why Orchestration Replaced Operation

The reason all three models are converging on the same operational reality is that AI now talks to infrastructure directly. It does not need the theater of a human interface to reach an API. It does not need a person to interpret a screen. It needs credentials, a clear definition of the desired end state, and the authority to act.

That changes what a professional day looks like. The old unit of competence was fluency inside a specific application: knowing the shortcut, knowing the report builder, knowing which menu hides the setting. That kind of expertise is now worth close to nothing, because the menu no longer needs to be navigated by a person. And the new unit of competence is orchestration — deciding which capabilities should be combined, in what order, under what constraints, toward what end.

The instrument metaphor is exact and worth holding onto. A player performs the notes written on the page. A conductor decides what the piece will be, what tempo it should breathe at, when the strings should recede so the horn can be heard, and what the audience should feel when the final chord lands. Nobody ever mistook a competent violinist for a conductor, and the difference was never technical skill. It was vision and judgment applied to an ensemble.

Today every company has access to an ensemble of startlingly capable instruments, most of which are idle or playing at the wrong time. The scarce resource is not capability. It is direction.

The Three Muscles of an Orchestrator

If orchestration is the work, what does the work actually consist of? Three capacities recur across organizations that are doing this successfully, and each one can be practiced.

  • System design through meta-cognition. The ability to stop seeing individual steps and start seeing a workflow as a system: inputs, transformations, feedback, failure modes. The valuable decision is not which task to do next but which agent should call which interface, under whose permissions, with what exception path. Connection architecture is the new competitive artifact.
  • High-resolution language. Taking a vague intention and decomposing it into tasks an agent can actually execute. This is often mislabeled as prompting technique. It is not a trick of phrasing; it is a measure of how clearly you think. Two managers with identical goals will get radically different results, and the difference is the resolution of their thinking, not the cleverness of their wording.
  • Aesthetic judgment about value. When a system can generate a hundred plausible outcomes, someone has to decide which one actually makes a customer’s life better. There is no correct answer to be looked up. Someone applies taste, experience, and a point of view, and signs off.

As software absorbs the labor and interfaces become transparent — the phenomenon sometimes called the invisible app — enterprise attention shifts entirely from owning tools to economic rationality. Nobody will pay for a dashboard. People will pay, happily and repeatedly, for a problem that stops happening.

What Happens to Cost When You Price the Result

The commercial evidence that this transformation is not a thought experiment is already in the benchmark data, and the numbers are striking enough to change budget conversations on their own.

Gartner’s comparison of support economics found that a human-assisted resolution costs roughly thirteen dollars and fifty cents, while an AI-driven self-service resolution lands near a dollar eighty-four. That is a gap of about seven times, on the same unit of work. McKinsey’s research points in the same direction from the demand side: organizations deploying AI report self-service usage rising two to threefold, with human-to-human interactions falling by forty to fifty percent across the service estate. Deloitte’s 2024 survey found that sixty-seven percent of organizations had already adopted some form of outcome-based outsourcing.

The strategic reading of those figures is not that headcount disappears. It is that capacity-based billing collapses under its own logic. Charging for the number of agents, seats, or licenses made sense when the constraint was human throughput: more people, more capacity, more cost. In an environment where a single orchestrated workflow can absorb the throughput of a team, paying for capacity is paying for a proxy that no longer tracks value. What a buyer wants to know is brutally simple: what does it cost me each time a customer problem is genuinely resolved?

There is an old line about customers not wanting a drill, they want a hole. RaaS is the industrial-scale version of that observation, and it arrives with a hard accounting edge. When you buy a hole, you can measure whether the hole exists. When you bought a drill, you could only hope the person holding it was competent. Outcome pricing converts hope into a line item.

How to Price a Result You Cannot Define Yet

The hard part of adopting outcome pricing is not belief, it is definition. A result must be countable, attributable, and defendable in a finance review, or the contract becomes a dispute waiting to happen. Four questions tend to make the difference between a workable agreement and a lawsuit.

  • What is the unit? A resolved ticket, a booked meeting with a qualified buyer, a reconciled ledger, a shipped feature. If two reasonable people cannot count it identically, it is not yet a unit.
  • Who controls the inputs? If the buyer can flood the system with unresolvable junk, the vendor absorbs risk unfairly. Define the boundary conditions as carefully as the price.
  • What counts as failure? Outcome pricing without an escape hatch becomes a hidden fixed-price contract with worse incentives. The honest version names the exclusions.
  • Where does judgment live? For subjective work, protect the iteration loop rather than forcing a premature deliverable. This is the Work-as-a-Service escape valve, and using it deliberately is not a retreat from ambition.

Organizations that answer those four questions before signing tend to move their portfolios toward outcome pricing incrementally: a support queue here, an outbound research workflow there, a reporting function next. Each migration is a small experiment in trust, and each one produces data that makes the next negotiation easier.

Rewriting the Operating System of Learning

There is a deeper implication that most business commentary skips over. If the economic contract between buyer and vendor is changing, the contract between a person and their own education must change too. The education system most of us inherited was designed for an industrial society: memorize procedures, demonstrate that you followed them correctly, and receive a credential that certifies you were trained. Call it OS 1.0. Its assumptions are being invalidated in real time, because the procedures it trains for are precisely what agents now perform better and faster.

What replaces it is a system built on the premise that external intelligence is always available. OS 2.0 rests on three capacities, and each one is a reversal of an old habit.

  • Abstraction. Stop memorizing granular procedures — the syntax of a language, the steps of a workflow — and start recognizing the underlying structure of a problem. Communicating structure rather than instructions to an AI is the strongest professional skill available today.
  • Backcasting. Instead of stacking up what you can currently do and hoping it adds to something valuable, begin from the result the customer needs and reason backward: what data, which models, what constraints, what sequence must exist for that end state to occur.
  • Discontinuous thinking. Skip the staircase. Do not learn A to reach B to eventually reach C. Build Z — a working prototype — on the scaffolding of AI, then work backward to understand why it does or does not function. In programming education, that means building a running application with a conversational model before memorizing grammar, then learning the fundamentals by investigating why something breaks.

The consequence for assessment is severe and liberating. The goal of learning stops being a license that proves you survived a process and becomes a result that proves you solved a real problem. The evaluator stops being a teacher and becomes a market. Credentials measure compliance with a curriculum; results measure usefulness to an actual human being. Only one of those is still scarce.

Verification as a Service and the Return of Liberal Arts

When AI takes over the process, it also introduces opacity. Decisions get made inside systems whose reasoning is not fully visible, at a speed no human can audit line by line. That opacity is exactly why certain human roles stop being decorative and become structural.

The most commercially interesting of these is verification. As process execution commoditizes, the SaaS vendor’s value proposition migrates from operating a tool to guaranteeing that a result is correct. An accounting platform stops selling journal entry screens and becomes a digital auditor certifying that an AI-generated financial statement is legally sound. The product is no longer the ability to do the work; it is the assurance that the work can be trusted. This is a much harder business to build and a much more durable one to own.

The second implication concerns the humanities, and it is the opposite of the usual prediction that philosophy and law become luxuries. In a world where computation produces an optimal answer by default, the scarce contribution is judging whether that answer is legitimate. Ethics, law, history, and philosophy are no longer cultural ornaments. They are the constraint code — the layer that decides which mathematically correct outputs are socially and morally permissible. A system that can calculate anything needs a governor that knows what it should be permitted to do.

Practical domains already feel this. A model can assemble a persuasive claim about a claim, a person, or a debt. Someone with moral and legal training has to decide whether that claim should be made at all. That decision is not automatable, because it is not a computation. It is a judgment about legitimacy, and it belongs to us.

Accountability Is the One Thing AI Cannot Assume

There is a boundary that technology does not cross no matter how capable it becomes, and it is not intelligence. It is responsibility.

An AI system can be accurate, fast, tireless, and occasionally brilliant. It cannot be accountable. It cannot stand in front of a customer and accept the consequences of a mistake, absorb the cost of a failure, or stake its reputation on a promise. Accountability requires the possibility of being blamed, and blame requires a someone. That structural gap is not a temporary limitation awaiting a better model. It is where human professional work concentrates permanently.

Which means the highest form of creative work available in this economy may turn out to be quite old-fashioned: declaring, in specific and binding terms, that this value will be delivered and that I personally answer for it. That declaration is not administrative overhead on top of the interesting technical work. It is the interesting work. It is what converts a calculation into a commitment, and commitments are what customers actually buy.

Who Decides What Happy Means

If outcomes are the product, then someone must define the outcome, and here the conversation stops being about software entirely. RaaS, at its best, is not a story about efficiency. It is a story about liberation — the gradual removal of work that was never the point. Nobody became an accountant because they loved reconciling spreadsheets. Nobody became an engineer because they enjoyed updating ticket statuses.

When the drudgery is absorbed, the remaining question is what the freed capacity is for. The honest answer is not that humans will now perform higher-order versions of the same tasks. It is that humans will return to being the authors of intent. The energy source that drives any of these systems is not compute. It is wanting someone specific to be better off, and being willing to organize real resources around that wish.

This is why the leaders who get the most from agentic systems are not necessarily the most technical people in the room. They are the ones with the clearest answer to two questions: who do I want to help, and will anyone else’s life actually be better because this thing exists? A system without that answer runs efficiently toward nothing.

Starting With the Outcome, Not the Tool

The practical invitation is narrower than the grand narrative suggests, and it starts this week. Stop scheduling time to learn the operations of a particular piece of software. That knowledge depreciates faster than you can acquire it, and the depreciation accelerates every quarter.

Instead, name a negative you can see in front of you. A queue that keeps growing. A report that takes three days. A handoff where information consistently dies. Define what its disappearance would look like, in terms countable enough to argue about. Then treat the available AI capability as an ensemble of instruments and ask how it should be arranged to reach that state: which system holds the data, which agent should act, where a human must sit in the loop, and what could go wrong badly enough to require a person’s signature.

That sequence — outcome first, orchestration second, tooling a distant third — inverts the reflex most organizations still have, which is to buy another application when something is slow. It also produces a different kind of professional, one who is measured not by familiarity with an interface but by the reliability of the outcomes they arrange for other people.

The opportunity in front of us is genuinely unusual. For the first time in a long while, the path to more value does not run through more ownership. It runs through less. Fewer tools to maintain, fewer screens to visit, fewer processes to survive. What remains is the part that was always the human part: deciding who deserves to be better off, and being the one who guarantees it happens. That is a smaller inventory and a much larger life, and it is available now, to anyone willing to hand the clicking over to the machines and keep the deciding for themselves.