If AI Makes Software Cheaper to Build, Should Clients Pay Less?

If a developer can do in two days what used to take a week, why is the client still paying for the week? It’s a fair question, and more clients are asking it.

Our view is straightforward. Clients should expect AI efficiencies to be reflected in the commercial value they receive, and suppliers should be able to explain how. But that doesn’t mean every project gets cheaper by the same amount, or that the invoice should simply follow the hours worked.

What Are Clients Actually Paying For?

Traditionally, software development has been priced around the people and time required to deliver it. A project needs a certain number of designers, developers and other specialists over an estimated period, and the cost reflects that effort.

AI challenges some of those assumptions. If a developer can complete in two days what previously took a week, it’s hard to argue that the original estimate should stay unchanged simply because that’s how the project would once have been delivered.

But clients aren’t just buying development hours. They’re paying for a working product that solves a business problem, performs reliably and can be maintained as their needs change. Writing code is only one part of that. Understanding requirements, designing the architecture, integrating existing systems, testing and security all still need serious attention.

The balance of effort is shifting, with some tasks becoming much faster while others, particularly reviewing and validating what AI produces, remain essential. That changes the cost of delivery, but it doesn’t remove the expertise and responsibility involved.

What This Looks Like in Practice

The following examples come from commercial projects rather than public sector engagements. They show what was achieved in specific circumstances, not improvements every organisation should expect.

On a global localisation platform, AI-assisted development helped the team deliver the original scope within the planned timeframe, with engineering allocation approximately 35% below the original estimate.

The team also used AI assistance to simplify part of the codebase. Work initially estimated at two to three months was completed by one engineer during a three-week sprint, replacing more than 70,000 lines of library-generated code with approximately 27,000. In a separate testing exercise, one engineer produced approximately 4,400 automated tests over two weeks using AI assistance.

On a food safety and sustainability platform, mobile application test coverage rose from 43% to 98% in less than three days, after an eight-week period in which progress had stalled. In a separate backend exercise, one engineer used AI assistance to take a failing continuous integration pipeline to 4,817 passing automated tests, with reported coverage of 96%, in around 43 hours.

Test counts and coverage figures don’t tell us everything about software quality. But alongside the time taken to achieve them, they help illustrate where AI is changing the effort involved. These examples demonstrate efficiencies in specific areas of delivery. They don't, by themselves, establish an equivalent reduction in total project cost or the savings passed on to clients.

The scale of the benefit will always depend on the nature of the project.

Faster Development Doesn’t Mean Every Project Gets Cheaper

Not all software projects benefit in the same way. A relatively straightforward application with well-defined requirements offers considerable room to reduce effort. A complex product involving legacy systems, sensitive information or demanding regulatory requirements is a different challenge. AI might accelerate parts of the implementation, but it doesn’t remove the need to understand how everything fits together, or the responsibility for security, reliability and what happens when something goes wrong.

There’s also the question of predictability, and it’s one buyers most need to understand. AI can make individual tasks dramatically faster, but that doesn’t make a whole project easier to estimate. Some work is finished almost immediately, while other problems still need significant investigation and specialist expertise. A faster task is not a more predictable project, and a price based on the fast tasks alone can end up wrong in either direction.

This is why AI-native product development has to be more than adding AI coding tools to an existing process. As we explored in What Happens When AI Can Build the Digital Product?, making software easier to produce doesn’t remove the need for good decisions about what gets built and how it works.

For clients, the important question isn’t just how much faster a supplier can write code. It’s how that efficiency affects the overall cost, timescale and quality of delivery.

Is It Time to Rethink Time-and-Materials Pricing?

If AI changes the relationship between effort and output, it also challenges commercial models built mainly around the time people spend working.

Time-and-materials can still make sense, particularly when requirements are evolving or scope is hard to define upfront. But it creates a tension when suppliers can deliver the same work in fewer hours. Clients will reasonably expect some of those efficiencies to be reflected in the commercial arrangement.

Suppliers, in turn, need pricing that reflects the expertise, responsibility and risk involved in delivering the result, not just the time spent producing it. If the cost of implementation falls, there may still be substantial work involved in defining the right solution, managing delivery and ensuring the finished product meets expectations.

That doesn't mean every engagement needs to move towards outcome-based pricing. Fixed-price, time-and-materials and outcome-linked models can all make sense, depending on the project. What matters is choosing an arrangement that reflects the scope, uncertainty and responsibilities involved.

Outcome-based pricing can help align incentives, but it isn't a simple replacement. Both sides need to agree what success looks like, which responsibilities sit with the supplier and what happens when requirements change. Without that clarity, a model designed to improve accountability can create a different set of disagreements.

This is where AI-native product strategy becomes particularly important. The clearer the problem, requirements and expected business value, the easier it is to agree what is being delivered, how it will be priced and how success should be measured.

Clients Should Expect More Transparency

As AI becomes a normal part of software development, clients will want to know how it’s affecting the projects they’re paying for. That doesn't mean accounting for every minute an AI tool saves. It means a clear explanation of how projects are estimated, where efficiencies are being achieved and how quality is being maintained.

Suppliers should be able to explain how AI is changing their delivery process and provide evidence of its impact. That means looking beyond individual productivity gains to understand what’s happening across the project, from engineering effort and delivery timescales to quality and ongoing maintenance.

That’s closely connected to our data-driven delivery approach, where we use delivery data and our in-house platform, Pulse, to understand performance, identify bottlenecks and measure whether changes to how we work are making a difference.

As we discussed in AI Means More Output. Does It Mean Better Work?, producing more in less time doesn't automatically mean better results. The same applies to software delivery, where gains in speed need to translate into tangible benefits, whether that's reduced delivery costs, faster time to market, improved quality or more scope for the same investment.

If AI is reducing the effort required to build software, clients are right to expect a benefit. That won't always mean a proportionately lower invoice, but it should mean a clearer relationship between what they're paying, the efficiencies being achieved and the value they're receiving.

Suppliers that can demonstrate that relationship will be in a much stronger position than those still pricing projects as though nothing has changed.