T&M, Fixed Price or Outcome-Oriented? Choosing the Right Commercial Model for Software Engineering Engagements.

Time and Materials, Fixed Price and outcome-oriented commercial models allocate uncertainty, control and delivery risk in different ways. None is universally better. The right model depends on how clearly the work can be defined, who controls the variables that influence delivery and whether the intended outcome can be measured and attributed.

The practical rule is simple: use Time and Materials where learning and adaptation matter most, Fixed Price where scope and acceptance criteria are genuinely stable, and outcome-oriented elements where the result is measurable and the Software Engineering Partner has enough control to influence it.

Commercial model	Best suited to	Main risk allocation	Typical failure mode
Time and Materials	Continuous agile product development, discovery, evolving scope and changing priorities	The Buyer retains most effort and productivity risk	Capacity is consumed without sufficient value or visible progress
Fixed Price	Stable, bounded and testable deliverables. Agile delivery practices may still be used, but commercial flexibility remains limited	The Partner assumes defined delivery-effort risk; the Buyer retains dependency and change risk	Hidden assumptions, change requests and optimization for formal acceptance
Outcome-oriented	Measurable results substantially influenced by the Partner. The solution may evolve iteratively if the intended outcome remains stable	Agreed performance risk is shared or transferred	Weak attribution, distorted incentives or an excessive risk premium
Hybrid	Agile cooperation requiring budget boundaries, milestones or a combination of predictable and uncertain work	Risk is allocated differently by phase or component	Commercial complexity and inconsistent governance

Commercial model and engagement model are not the same decision

An engagement model defines how a Software Engineering Partner contributes: for example through Project Delivery, a Dedicated Team, Team Extension, a Managed Capability or Forward Deployed Engineers. The commercial model defines how that contribution is priced and how financial risk is distributed.

The two decisions are connected, but they should not be collapsed into one. A Dedicated Team is often priced on a Time and Materials basis, but it may include capacity commitments, service levels or outcome-linked incentives. A project can be Fixed Price, priced by milestones or delivered through a capped Time and Materials model. A Managed Capability may combine a recurring baseline fee with service levels and outcome components.

Tech Buyers should therefore first clarify the required responsibility and collaboration model, then choose a commercial structure that fits the uncertainty and control conditions of the engagement. ValueLeap’s overview of Software Engineering Sourcing Models supports the first of these decisions.

When Time and Materials is the better fit

Time and Materials is useful where priorities, requirements or technical understanding will evolve during delivery. The Buyer pays for the capacity and expertise used rather than for a fully predetermined output.

It is often appropriate for product development, discovery-led work, modernization, complex integration, AI engineering and other contexts in which learning changes the next best action. It also fits Team Extension and Dedicated Team models where the Tech Buyer retains substantial product and delivery control.

The main advantage is adaptability. In typical agile cooperation, Time and Materials supports shared learning and reprioritization without fixing the entire product scope upfront. The main risk is that effort becomes the commercial unit while progress and value receive too little attention. Effective Time and Materials governance therefore requires a clear product direction, transparent backlog and priorities, visible delivery metrics, strong technical leadership and regular decisions about whether continued effort is justified.

Pure Time and Materials can also weaken Buyer-side discipline if delivery continues without timely decisions, feedback and acceptance. Sprint-based commitments and formal reviews create mutual accountability: the Partner demonstrates the agreed results, while the Buyer provides direction, resolves dependencies and approves what has been delivered. This makes emerging delays, budget pressure and necessary scope decisions visible while both sides can still respond.

Time and Materials is usually suitable when:

• the problem is clear but the detailed solution or scope is still evolving;
• the Buyer needs flexibility to reprioritize work;
• the Buyer retains product ownership and important delivery decisions;
• learning, experimentation or technical discovery is part of the work;
• the proposed team and delivery transparency can be validated.

When Fixed Price is the better fit

Fixed Price can work well when deliverables, boundaries, dependencies and acceptance criteria are sufficiently clear. The Partner commits to an agreed output for an agreed price and assumes more of the delivery-effort risk.

It is most credible for bounded work packages, well-understood implementations, defined migrations, assessments or other deliverables with limited uncertainty. It is less suitable where the apparent certainty comes mainly from documenting assumptions that are likely to change.

A fixed price does not remove uncertainty. It prices and reallocates it. The Partner may include a risk premium, narrow the interpretation of scope, rely on change requests or optimize for formal acceptance rather than the best business result. The Buyer also retains risks related to unclear requirements, delayed decisions, unavailable environments, changing dependencies and stakeholder alignment.

Fixed Price is usually suitable when:

• the scope and expected deliverables are stable and testable;
• dependencies and Buyer responsibilities are understood;
• acceptance criteria can be agreed before delivery;
• changes can be governed without distorting the objective;
• the Partner has relevant evidence for comparable delivery.

When outcome-oriented models make sense

Outcome-oriented models link part of the commercial arrangement to an agreed result rather than only to hours, capacity or completed scope. The outcome might concern a product, operational performance, service quality, speed, cost, reliability or another measurable business or engineering result.

These models are attractive because they appear to align incentives. But alignment is only real when the outcome is clearly defined, observable and materially influenced by the Partner. If adoption, internal decisions, data quality, third-party systems or market conditions determine the result, transferring the full outcome risk to the Partner may be unrealistic or expensive.

Outcome orientation is therefore often more practical as a component of a commercial model than as a pure replacement for all other pricing. A baseline fee can fund the team and required capability, while milestones, service levels, gain-sharing or performance components reward agreed results.

Outcome-oriented elements are usually suitable when:

• the intended outcome can be defined and measured credibly;
• the baseline and measurement period are agreed;
• the Partner controls or strongly influences the relevant delivery variables;
• Buyer and Partner responsibilities are explicit;
• the incentive does not encourage shortcuts or local optimization.

How AI-assisted delivery changes the commercial discussion

AI-assisted software development can reduce the effort required for some engineering tasks, increase the leverage of senior specialists and make small teams more productive. This weakens the assumption that hours consumed are always a useful proxy for value created.

It does not mean that Time and Materials is obsolete. In uncertain work, paying for adaptable expertise may still be more rational than asking a Partner to price unknown scope. The important change is that Tech Buyers should pay closer attention to team composition, AI-enabled delivery practices, cycle time, quality, ownership and achieved progress rather than treating headcount or utilization as the main performance signal.

Fixed Price also does not automatically allow the Buyer to capture all AI productivity gains. Partners price risk, and competitive markets will determine how quickly improved productivity is reflected in proposals. An inflexible fixed scope may still slow learning or encourage the wrong optimization.

Outcome-oriented models become more relevant as the relationship moves from purchasing effort toward purchasing responsibility and results. But they require better measurement and clearer boundaries, not less governance. The related Insight How AI-Native Engineering Changes What Tech Buyers Need from Software Engineering Partners explains how AI also changes the capabilities and operating fit Buyers should evaluate.

Fixed Price and outcome-linked elements become more viable when the commercial commitment is limited to a short delivery period, milestone or product increment. A shorter estimation horizon reduces the Partner’s exposure to changing assumptions, dependencies and priorities. Agile sprints can provide regular points for agreeing commitments and accepting completed increments. AI-assisted delivery can shorten these cycles further and improve testing, traceability and delivery visibility, allowing output and quality to be assessed earlier. This does not eliminate risk, but it can make the risk more bounded, measurable and commercially manageable.

Hybrid commercial models are often more realistic

Many software engineering engagements contain both predictable and uncertain work. A hybrid structure can reflect this more accurately than forcing the entire relationship into one model.

• Discovery followed by Fixed Price: use a short Time and Materials discovery phase to clarify architecture, scope, dependencies and acceptance criteria before pricing a bounded delivery phase.
• Capped Time and Materials: retain flexibility while setting a budget boundary and explicit decision points.
• Performance-adjusted Time and Materials: retain flexibility while linking a limited part of compensation to agreed delivery, quality or predictability measures. In agile delivery, commitments can be defined after backlog refinement and reviewed through sprint results without fixing the entire product scope upfront.
• Milestone-based delivery: connect payments to defined intermediate outputs while retaining controlled flexibility between milestones.
• Baseline fee plus outcome component: fund the Partner’s team or managed capability while linking part of compensation to measurable performance.
• Fixed core with variable backlog: price a stable foundation separately from features or changes that remain uncertain.

Performance-adjusted Time and Materials can be particularly effective when Buyer and Partner teams collaborate remotely across company borders rather than working together onsite. Short delivery commitments, transparent measures and regular reviews provide additional management control where informal coordination and physical proximity are reduced. The model nevertheless depends on strong Delivery Management, clear decision rights, effective cooperation between customer-side roles and their empowered remote counterparts, sufficient working-hour overlap, a shared spoken language and cultural and collaboration fit. It is less suitable where large time-zone differences make frequent joint meetings and timely decisions difficult, as can be the case in distant offshore setups.

Choose the model by testing uncertainty, control and measurability

Before selecting a commercial model, Tech Buyers should ask:

• How stable are the problem definition, scope and acceptance criteria?
• Which uncertainties are likely to change the work?
• Who controls priorities, architecture, dependencies, environments and decisions?
• What result can be measured without creating misleading incentives?
• Which risks should the Partner reasonably price and assume?
• Which Buyer obligations must be fulfilled for the model to work?
• How will changes, learning and unresolved assumptions be handled?
• Which governance and evidence will show whether the engagement is progressing?

Evaluate whether the Partner can operate the proposed model

A commercially attractive proposal is not enough. The Software Engineering Partner should demonstrate that its delivery system, governance and experience fit the proposed model.

For Time and Materials, validate the proposed team, transparency, product collaboration and ability to turn flexible capacity into visible progress. For Fixed Price, examine comparable delivery evidence, estimation assumptions, dependency management, acceptance logic and change governance. For outcome-oriented elements, test measurement quality, causal influence, shared responsibilities and protection against unintended incentives.

These questions belong in the wider Partner decision rather than being treated as a procurement appendix. ValueLeap’s Software Engineering Partner Selection framework shows how commercial fit can be evaluated alongside capabilities, team and collaboration fit, qualifications, evidence and unresolved risks.

The objective is fit, not a universal winner

Time and Materials offers flexibility but requires active governance. Fixed Price can create budget and delivery clarity when the work is genuinely definable. Outcome-oriented models can improve alignment when outcomes are measurable and responsibilities are controllable. Hybrid models often provide the most realistic balance.

The right choice is the model that reflects the actual uncertainty of the work, allocates risk to the party best able to manage it and supports the behavior needed for successful delivery.

ValueLeap helps Tech Buyers define sourcing, engagement and commercial requirements, compare suitable Software Engineering Partners and validate whether a proposed delivery and commercial model fits the specific sourcing need. Learn more about our Selection Advisory.