Back to the blog

From software access to work completed

AI is not killing SaaS: it is changing what companies sell, how they charge, and what responsibility they assume when software performs work.

“SaaS is dead.”

“The future is Service as Software.”

“Companies will stop paying for people and start paying for outcomes.”

As with many claims surrounding artificial intelligence, an important idea is mixed with considerable exaggeration.

I do not believe one model will suddenly disappear and be replaced by another. The change that interests me is deeper and, at the same time, easier to explain:

For years, we sold access to software. Now we are beginning to sell work performed by software.

That distinction can transform how products are built and priced, how outsourcing works, what productivity means, and which responsibility a provider assumes.

What SaaS actually sold

Before the cloud, we typically bought a license, installed a program, and waited for the next version.

Software as a Service changed that relationship. Instead of buying a copy, we paid a monthly or annual subscription for continuous access to an updated product.

The economic unit was often simple:

number of users × price per user per month

The model worked extraordinarily well because it produced recurring, predictable revenue. It also reflected how work happened.

A person performed a task, and a tool helped them:

  • The CRM helped the salesperson.
  • The support platform helped the support agent.
  • Design software helped the designer.
  • The development environment helped the programmer.

The company bought access to a tool. People continued to perform the work.

When software stops merely helping

Generative AI and agents introduce something different.

The system no longer merely displays information or facilitates an operation. It can interpret a request, retrieve data, use tools, participate in a decision, and complete a task previously performed by a person.

There is no need to anthropomorphize it. Software does not become a human worker. But it starts executing activities that belong to the labor market.

The purchasing question therefore changes.

It used to be:

“How much would I pay for a tool that helps my team work better?”

It may now become:

“How much would I pay to have this work completed?”

That is the central shift: from selling access to selling execution.

The customer support example

Imagine a company with one hundred customer support employees. Under a traditional model, one hundred human agents might mean one hundred licenses for a support platform.

The product now adds an AI agent that automatically resolves some inquiries. The company may need fewer people for repetitive cases while retaining human specialists for exceptions, oversight, and sensitive conversations.

The software produces more value, yet the vendor could earn less if revenue depends only on the number of human users.

The better the automation works, the fewer seats the customer needs.

That is why other pricing units are emerging. Salesforce, for example, combines licenses with conversation pricing and consumption tied to agent actions. This is not the complete abandonment of subscriptions; it is a sign that one metric is no longer enough.

The product begins to say:

“Do not pay me only so your team can use me. Pay me for the work I execute too.”

The economic unit is changing

Every business model needs some unit that approximately represents what the customer buys.

In SaaS, it was often the monthly user. In infrastructure, it may be storage, requests, or compute hours. In consulting, it is usually hours, days, or people.

Agents make other units measurable:

  • A resolved conversation.
  • A processed invoice.
  • A reviewed document.
  • An answered call.
  • A completed task.
  • A finished migration.
  • An executed action.
  • A verifiable outcome.

The question is no longer only how many people use the product. It also becomes how much work the product performs.

Not every unit represents value equally well. Counting actions may incentivize unnecessary activity; counting outcomes requires defining and verifying them. Both, however, sit closer to execution than a seat license.

Software begins to compete with services

Consider an accounting system.

If it helps accountants perform reconciliations, it competes with other tools and comes from a technology budget.

If it performs much of the reconciliation itself, it can also be compared with internal employees, an outsourcing provider, or an accounting firm.

Software begins competing for operating and service budgets, not only technology spending.

This is one reason the idea is so attractive to companies and investors. The labor market is much larger than the software market. A product capable of capturing some of the value associated with execution can justify a much higher price than an auxiliary tool.

But to capture that value, it must prove the work was completed correctly.

The problem with billing effort

The same tension appears in outsourcing and consulting.

A significant part of the industry sells capacity through staff augmentation: the client needs five developers, and the provider integrates five people into its team for a period.

The model remains useful. Projects can be uncertain, systems complex, and organizations may need to expand capacity temporarily.

When the provider bills hours, however, AI can invert its incentives.

Imagine two consulting firms:

  • One needs ten people for six months.
  • Another uses agents, automation, and better processes to deliver the same result with five people in three months.

The second is more efficient, but it may invoice less if both charge exclusively for effort.

AI did not invent this problem. Billable hours have always been an imperfect proxy for value. AI amplifies the difference.

If productivity improvements are large, effort becomes increasingly difficult to use as the only basis for price.

From selling people to selling a production machine

This does not mean staff augmentation will disappear.

What may weaken is the idea that more people automatically mean more value.

A service company could offer a given level of engineering capacity supported by a combination of:

  • Developers and specialists.
  • Programming agents.
  • Automated test generation and execution.
  • Specialized reviews.
  • Internal platforms.
  • Deployment and observability systems.
  • Proprietary processes and intellectual property.

The client does not buy each component separately. It buys the machine's capacity to produce.

The company stops looking only like a talent intermediary and begins to resemble a knowledge factory composed of humans, agents, tools, and processes.

When it charges for capacity or a deliverable, improving that machine can increase its margin. Efficiency no longer punishes it.

The attraction and difficulty of outcome pricing

The extreme version of this transition is selling the outcome directly:

  • A completed migration.
  • One thousand resolved requests.
  • One hundred correctly processed documents.
  • An application operating under defined conditions.

The model seems ideal because it aligns incentives. The provider benefits from efficiency, and the customer pays for what they need.

The difficulty lies in defining what counts as an outcome.

If an agent contacts one hundred prospects and one buys, did the agent produce the sale, or was it advertising, the human salesperson, the price, or a preexisting need?

Business outcomes often have multiple causes. They may also appear later, depend on customer data, or fall outside the provider's control.

Outcome pricing transfers risk as well. If execution costs money but the final criterion is not met, the provider may not be paid.

We will therefore probably see hybrid models:

  • A base subscription plus consumption.
  • Licenses plus actions.
  • Fixed price plus outcome incentives.
  • Contracted capacity with service levels.
  • Payment per task when the task can be verified.

There is no single correct metric for every product.

SaaS is not dying

Subscriptions still make sense for editors, design tools, collaboration platforms, management systems, and many other products.

Even a product with agents can combine access, consumption, and outcomes.

What is losing universality is this assumption:

“The value of software depends on how many people log in to use it.”

A product used by ten people may perform work that once required one hundred. If it charges only for those ten users, its price may become disconnected from the value it produces.

The important question is not whether SaaS died.

It is:

“Which unit best represents the value this software delivers?”

When you sell work, you sell reliability

If a product sells access, user experience is central: interface, onboarding, features, adoption, and renewal.

If it sells completed work, other requirements emerge:

  • Was the work done correctly?
  • Can that be demonstrated?
  • Is it traceable?
  • What happens when it fails?
  • Who handles exceptions?
  • When does a person intervene?
  • Which permissions does the agent receive?
  • How is an incorrect action reversed?

Observability, evaluations, controls, auditing, security, and human oversight stop being technical extras. They become part of the product the customer purchases.

Putting a chatbot on top of an existing application is not enough. Delivering execution requires a reliable operational system.

When you sell work, you also sell accountability

If a company sells a calculator and the user enters the wrong number, the boundary of responsibility is relatively clear.

If it sells an agent that processes payments, approves requests, sends contracts, or modifies systems, that boundary changes.

The provider no longer supplies only a tool. It participates in execution and must therefore assume greater responsibility for errors, controls, and recovery.

It is inconsistent to promote agents as workers when selling their capabilities and treat them as neutral tools when something goes wrong.

Commercial trust will depend on contracts, guarantees, boundaries, evidence, and remediation mechanisms compatible with the autonomy being offered.

Developer productivity changes too

For a long time, we imagined developer productivity as a person's ability to program and solve problems.

With agents, one person can operate a larger production system:

  • They design a flow that generates tests.
  • They coordinate agents reviewing different concerns.
  • They define how documentation is produced and validated.
  • They supervise multiple tasks in parallel.
  • They decide what requires human intervention.

The question is no longer only how many lines someone can write or how many programmers AI will replace.

It becomes how much productive capacity one person can direct responsibly with these systems.

The outsourcing challenge

A consulting firm whose main advantage is offering many developers at a lower cost will continue facing wage competition, but also a new pressure.

If headcount stops directly determining output, other factors become more important:

  • The quality of the delivery system.
  • Domain knowledge.
  • Agent infrastructure.
  • Validation processes.
  • Internal tools.
  • Accumulated intellectual property.
  • The responsibility the provider accepts.

Wage arbitrage does not disappear, but it becomes relatively less important than the ability to produce reliable outcomes.

Companies that turn their experience into a production machine can capture the benefit of automation. Those that continue to sell only hours will have to explain why efficiency should not reduce their revenue.

Software and services begin to merge

For decades, we maintained a clear boundary: software companies built products, and service companies sold work.

When software performs work, that separation becomes blurry.

A SaaS company starts acquiring service characteristics: execution, oversight, guarantees, and accountability. A consulting firm that builds agents, platforms, and internal automation begins to resemble a product company.

We will likely see hybrid organizations combining software, humans, agents, operations, and services in one offering.

That convergence may matter more than any new acronym.

The real shift

We do not know which model will win because there will probably not be just one.

Subscriptions, licenses, consumption, staff augmentation, fixed-price work, and hourly contracts will remain. Payments for actions, tasks, and outcomes will join them, along with many combinations.

The direction worth watching is different.

Software is moving beyond saying:

“Here is a tool.”

It is beginning to say:

“Tell me what you need done.”

When that happens, the unit of value, the product, the market, and accountability all change.

For decades, we built software so people could do things. Now we are beginning to build software that does things.

This is not the death of SaaS.

It is the beginning of a different relationship between software and work.

References


This article grew out of a reflection on SaaS, outsourcing, and how agents are changing software economics. You can watch the original video on YouTube.

Keep reading

View all articles