Walter Technologies
Engineering

Why IT Services Are Moving From Hourly Billing to Fixed-Price Contracts

Walter Technologies5 min read

India's largest IT services firms are shifting billing models fast. Cognizant now generates roughly 47% of revenue from fixed-price contracts; Infosys is at 54%. Both numbers have climbed sharply as AI tools cut the hours needed for coding, testing, and maintenance work that used to anchor time-and-material (T&M) billing. This isn't a pricing experiment — it's a structural change in what clients are actually paying for, and it's worth understanding regardless of which side of the contract you sit on.

Why time-and-material billing is losing ground

T&M billing works cleanly when effort and output are roughly proportional: more hours reasonably means more delivered work, so billing by the hour is a fair enough proxy for value. AI-assisted development breaks that proportionality. A task that took 20 hours last year might take 6 this year, with the same or better quality — and under T&M, that efficiency gain shows up as less revenue for the vendor, not more margin. The incentive structure actively punishes the provider for getting faster.

That misalignment is the real driver behind the shift, more than a client-side push for lower costs. Vendors that keep billing by the hour are penalized by their own productivity gains. Vendors that move to fixed-price or outcome-based contracts capture the value of those gains as margin instead of giving it away.

What fixed-price and outcome-based actually mean

Fixed-price means the client pays an agreed amount for a defined scope, regardless of how many hours it actually takes. The vendor absorbs the risk if it takes longer than estimated, and captures the upside if AI tooling or process improvements make it faster.

Outcome-based goes further — payment ties to a measurable result (a support ticket deflection rate, a processing time reduction, a specific business metric) rather than to a deliverable at all. This is less common than fixed-price but growing, particularly in AI and automation engagements where the point of the work is a measurable operational change.

Both models shift the fundamental question a client asks from "how many hours will this take" to "what will this actually get us, and what does that cost."

Why this favors clients who know what they want

Fixed-price contracts reward clarity of scope. A well-defined project — clear requirements, clear acceptance criteria — is straightforward to price fairly under a fixed-price model, and the client gets cost certainty in return. A poorly scoped project is where fixed-price contracts go wrong on both sides: the vendor prices in risk buffer for the ambiguity, the client pays for uncertainty they didn't need to create, and change requests become an adversarial negotiation instead of a normal part of iterative work.

This is exactly why a dedicated team model and a fixed-price project model solve different problems, and why the shift toward fixed-price doesn't mean T&M or capacity-based engagement is obsolete. Ongoing product development, where requirements evolve as you learn — a dedicated team, priced for capacity, still makes more sense than trying to fix-price something that isn't actually fixed yet.

What this means if you're evaluating an engineering partner right now

A few practical implications worth carrying into that conversation:

  • A vendor still billing pure hourly rates for well-defined, repeatable work is likely leaving efficiency gains on the table — or not passing them to you. If AI tooling is cutting their delivery time, ask directly how that shows up in your pricing, not just theirs.
  • Fixed-price only works well with real scope clarity. If you're asking for a fixed price on something you can't yet describe precisely, you're either paying for padded risk or setting up a change-request fight later. Sometimes the honest answer is "let's nail down scope first," not "let's fix the price now."
  • Outcome-based pricing is worth asking for on AI and automation work specifically, because the entire point of that work is a measurable operational change — a support deflection rate, a processing time cut, a headcount-equivalent freed up. If a vendor can't articulate the outcome they're targeting, that's worth noticing before signing anything.
  • The shift doesn't eliminate the case for dedicated, capacity-based teams. It sharpens the distinction between "buy an outcome" and "buy ongoing capacity and judgment" — see our take on dedicated teams vs. project-based agencies for how to tell which one your situation actually needs.

The underlying trend — AI compressing delivery time, and pricing models adjusting to capture that as margin rather than give it away — isn't specific to India's largest firms. It's the direction the entire industry is moving, and it's worth factoring into how any engineering engagement gets scoped and priced going forward.

Start a conversation

Have a software problem worth solving?

Tell us what you're building, automating or modernizing. We'll help you determine the right technical approach.