The better your team gets at delivering with AI, the less you earn under Time and Materials (T&M). That is not a bug. The contract is working exactly as designed, for a world that no longer exists — one that digital transformation has already left behind.
Why hours used to work as a proxy for value
For many years, hours were a reasonable stand-in for value; if you wanted more value, you bought more hours. Engineers were paid for the time they spent working, and clients paid for the time that they used. The system stayed stable because the two sides of the equation — time spent and value produced — moved more or less in tandem. AI-native delivery broke that proxy.
A team that has made the shift no longer produces value proportional to the hours worked. Sometimes, they produce three times the value in the same amount of time. Sometimes, they produce the same value in a third of the time. The relationship between hours and outcomes — the entire foundation of how we priced software for forty years — is gone. And the contracts haven't noticed.
The paradox: Get faster, earn less
Time and Materials was based on a simple principle: the vendor received payment according to the amount of work done, and the client could see how the money was being spent. Since transparency was involved, both the vendor and the client shared the risks. This approach proved successful. For a long time, it was the industry's most honest method of pricing.
Then the vendor got dramatically better. The client doesn't get three times the value — they get the same outcome, earlier, with fewer hours on the invoice. The vendor doesn't get rewarded for the investment in methodology, in Context Engineering, in the painful transition to AI-native practice. They get rewarded with a smaller check.
This is the paradox: in the model we inherited, the better you get, the less you earn. Not because the client wanted less. Because of the structure of the contract itself. The penalty is not a bug. It is the model working exactly as designed — for a world that no longer exists.
What the Client, the Team, and the Vendor actually want
The easiest way to see why Time and Materials cannot adapt to AI-native delivery is to look at what each party wants, and what the model gives them.
The Wave Model: 4 stages that replace hours with outcomes
Concepts are cheap. What makes a pricing model real is how work flows through it. Here is what a Wave looks like in motion.
A Wave begins with a short working session, not a Statement of Work. The client brings the next item from their priority queue. The team, with AI support, helps sharpen it: what product outcome we're solving for, the boundaries, what "done" looks like, and the success criteria. The output is a clear enough understanding to start building — not a specification document. Typically minutes to a few hours, depending on the size of the Wave.
The team takes the outcome through all stages, from the initial scope to deployment. AI is used at every stage to identify edge cases, produce the code, and check the assumptions against the project's knowledge base; it is in this phase that the acceleration curve has its effect. The team is not recording hours; instead, they are getting the outcome from intention to implementation.
When the outcome meets its criteria, the Wave closes with a short Receipt: original intent, what was delivered, tests passed, deploy checklist, and constraints. Both sides sign; payment is triggered. Over a year, these Receipts form a record of what was actually delivered — a very different conversation than scrolling through a timesheet.
Validation is not a gate at the end — it runs in parallel with Build. Tests are written alongside code. The outcome is demonstrated against the success criteria defined in Intent. If it fails, the Wave doesn't close — it iterates.
Wave sizing: Classifying outcomes instead of estimating hours
Waves are not uniform. They come in three practical sizes, classified at Intent, not afterwards:
- Small: A well-defined, single-purpose outcome in a known domain. A CRUD module, a new endpoint, a configuration change.
- Standard: A complete business workflow with moderate complexity and multiple integration points.
- Deep: Architectural decisions, cross-cutting system impact, or high uncertainty — authentication systems, data pipelines, AI features like GenAI integrations, conversational AI, machine learning pipelines, and AI agents, or significant third-party integrations.
Size isn't measured in hours. It is measured in scope and depth — how far the Wave reaches into the system, how many assumptions it must resolve, how much uncertainty it carries. This is why sizing is a conversation, not a calculation.
It is also why the model starts with a Wave Sizing Session — a short working meeting before any contract is signed, where the team walks the client through their initial priority queue and assigns sizes to each item. The client sees how the methodology thinks. The team sees how clear the client's intent is. Both sides leave knowing whether the engagement is ready to move forward.
An end-to-end example: T&M vs. the Wave model
A customer experience initiative requires a new onboarding process — account creation, identity verification, initial preferences, and the welcome sequence. In the case of a traditional time and materials engagement, this is put into the form of a Statement of Work. A team is then put together, hours are logged, and change requests arise whenever the scope turns out to be more complex than what was suggested in the document.
The Wave model looks different. The onboarding workflow goes into the client's priority queue. At Intent, it's sized as a standard Wave — clear boundaries, moderate complexity, two integration points. The success criteria are simple: a user can complete onboarding start to finish, identity gets verified, preferences get stored, the welcome sequence fires.
The team builds and tests as they go, checking in with the client on the few decisions that come up along the way. Once the outcome meets those criteria, the Wave closes with a Receipt. The client pays for the onboarding workflow — not for the hours it took to build it.
Meanwhile, the next item in the queue — say, a reporting dashboard — is already taking shape in Intent. The team just moves to it. No renegotiation, no change request. The model keeps going.
How outcome-based pricing reshapes the client relationship
Pricing models don't just decide how invoices are calculated. They shape the working relationship. Under T&M, the client writes a Statement of Work. The vendor executes against it. When the world changes — which it always does — the client writes a change request. The mechanism is adversarial by default: both sides are protecting themselves against the document they signed.
Under outcome-based pricing, the Statement of Work is replaced by a priority queue of intents — the outcomes the client wants, ordered by what matters most right now. The team pulls from it. The client owns the ordering. Nobody argues about scope; they re-prioritise.
This is a quieter revolution than it sounds. The client stops being a reviewer and becomes a participant in what gets built next. The team stops being a contractor waiting for clarifications. It becomes a partner responsible for turning a priority into a delivered outcome — the whole dynamic moves from defending a contract to co-managing a backlog of value.
The commercial mechanics that make this work:
- Delivery velocity, not team size. Instead of buying a team size, the client subscribes to a delivery velocity — how many Waves per month they want closed. The vendor manages the capacity to meet it.
- Modular by design. A client can buy a single Wave to test the approach, subscribe to a monthly velocity and adjust it month to month, or combine both — a baseline velocity plus on-demand Waves when something urgent appears between planning cycles. Every mode is priced the same way, per Wave, so mixing them creates no accounting complexity.
- Wave Bank. Unused Waves don't evaporate at the end of the month — they accumulate, up to a defined cap, so the client can save capacity and deploy it as a burst when they need to accelerate.
- Velocity Guarantee. If a committed Wave is late due to the team, the next small Wave is on the vendor.
These are structural consequences of selling outcomes, not hours. A vendor who controls outcomes can price, bank, and guarantee them. A vendor who sells hours cannot honestly do any of the three.
Risk-sharing stops being a slogan and becomes a mechanism. Under T&M, delivery speed is a vendor claim often promised, rarely enforceable. Under outcome-based pricing, speed becomes a shared commitment: both sides have skin in the game in how fast outcomes close. For the client, this is the first model in which scope risk and delivery risk genuinely belong to the vendor, not as legal language, but as structure.
The plan–build–run arc finally belongs to one partnership. Traditionally, it got handed off between three different contract types — advisory, project delivery, managed service — each with its own commercial structure and renegotiation cycle. Outcome-based pricing collapses that into a single continuous engagement, structured around what gets delivered rather than which ceremony is being performed.
4 honest limitations of the wave model
Every pricing model is an approximation. This one is too, and it is better to name its limits than let them surface mid-engagement.
A Wave can be small or large; the value can be sharp or diffuse. Two honest professionals can look at the same outcome and estimate it differently — the same estimation challenge that shows up whenever teams try to size AI-native work. Outcome-based pricing doesn't remove estimation from the equation. It relocates it — from hours on a task to the scope of an outcome. The model is only as trustworthy as the sizing conversation that precedes it.
Capability-based work involves a specialist embedded in a client team for a defined period, working on whatever comes up. That's legitimately priced by rate card, because the value lies in the specialist's presence, not in a discrete outcome. The Wave model applies where there are outcomes to define. It doesn't replace every other pricing structure. It adds a new one where AI-native delivery makes the old ones unfit.
This model won't make pricing a simple matter; instead, it transfers the difficulty from "how many hours will this take" to "what exactly do we mean by this outcome and how do we know that it's complete". That discussion is more challenging at the start and becomes easier thereafter — since once clarity has been established it doesn't need to be re-negotiated every two weeks.
Both sides are learning. The team is calibrating how its real acceleration curve translates into Wave classification. The client is learning how to manage a priority queue instead of a change-request process. Name this in the first conversation, not discover it halfway through.
Why pricing is a statement about what the work is
Pricing is never just pricing. It defines what the client is buying. When we sold hours, we were selling effort and time. In traditional consulting, that made sense because effort and value were closely linked.
AI consulting changes that equation. AI-native delivery can reduce months of work to weeks, separating effort from value. So our commercial model needs to evolve with the work.
Selling outcomes aligns our pricing with what we actually deliver. This is not a repricing trick; it is a recognition that the nature of the work has changed. If the unit of sale does not match the unit of value, AI-native delivery will always hit a ceiling. It is time to change the unit — from hours to outcomes.
Related Insights
The breadth of knowledge and understanding that ELEKS has within its walls allows us to leverage that expertise to make superior deliverables for our customers. When you work with ELEKS, you are working with the top 1% of the aptitude and engineering excellence of the whole country.
Right from the start, we really liked ELEKS’ commitment and engagement. They came to us with their best people to try to understand our context, our business idea, and developed the first prototype with us. They were very professional and very customer oriented. I think, without ELEKS it probably would not have been possible to have such a successful product in such a short period of time.
ELEKS has been involved in the development of a number of our consumer-facing websites and mobile applications that allow our customers to easily track their shipments, get the information they need as well as stay in touch with us. We’ve appreciated the level of ELEKS’ expertise, responsiveness and attention to details.
