The problem is not that software delivery is expensive. The problem is that most pricing models charge for the wrong thing. Time and materials charges for hours regardless of output. Fixed-price charges a single number for scope that rarely stays stable. Dedicated teams charge for headcount regardless of velocity. Each model survives because procurement teams know how to evaluate it — not because it actually aligns vendor incentive with customer outcome.
This piece walks through the three legacy pricing models, why each fails in a predictable way, and how outcome-based delivery via Delivery Units replaces all of them with a primitive that aligns vendor and customer around the same goal: shipped, accepted output.
The three legacy pricing models
1. Time and Materials (T&M)
T&M is the dominant pricing model for staff augmentation, contractor engagements, and most Big-IT services work. The customer pays an hourly rate for engineer time. The vendor's revenue is hours billed. Scope changes mean more hours; ramp time means more hours; bench time during scope-clarification cycles means more hours.
What T&M solves: easy procurement evaluation (compare hourly rates), low contractual friction (everyone understands hours), and scope flexibility (just add more hours).
What T&M breaks:
- Vendor incentive misalignment. Vendors profit when work takes longer. The customer's job becomes policing timesheets — a structurally adversarial dynamic.
- Hidden cost compounding. Headline rate of $80/hour balloons to effective $130-160/hour once management overhead, ramp tax, bench tax, knowledge attrition, and scope-change cycles are accounted for. The honest comparison is via Total Cost of Delivery, not rate cards.
- Customer absorbs all delivery risk. If the vendor is slow, the customer pays. If the engineer ramps slowly, the customer pays. If scope is unclear, the customer pays for clarification time.
- Outcome accountability is structurally impossible. The vendor cannot lose money on slow delivery — only the customer can.
2. Fixed-Price
Fixed-price contracts assign a single number to a defined deliverable. The vendor commits to shipping the scope for the price; the customer commits to paying when shipped. Sounds clean — until scope shifts.
What fixed-price solves: cost predictability (one number on the budget line), upfront accountability (vendor's commitment is visible), and procurement simplicity (compare bids easily).
What fixed-price breaks:
- Scope assumptions don't survive contact with reality. Modern software engagements rarely have fully stable scope. Change orders are slow, expensive, and often more painful than the change itself.
- Vendor prices the risk into the upfront number. Smart vendors load 25-40% risk premium into fixed-price quotes to protect against scope evolution. The customer pays for risk that may never materialize.
- Quality-vs-deadline trade-offs go to deadline. When the vendor commits to a fixed price for a fixed scope, the only flex when problems emerge is quality. Cut corners ship; quality debt accumulates.
- Scope creep becomes adversarial. Every customer change request becomes a vendor revenue opportunity (change orders). Every vendor scope reduction becomes a customer cost-saving demand. The relationship turns transactional fast.
3. Dedicated Teams (Per-FTE Subscription)
Dedicated team pricing — selling X engineers fully allocated to the customer's engagement at $Y/month — is common across offshore vendors and modern remote-first agencies. The customer rents named engineers; pricing is per-FTE-per-month regardless of velocity.
What dedicated teams solve: capacity stability (the team is yours), vendor-handled employment (no direct contractor relationship), and predictable monthly cost.
What dedicated teams break:
- Customer pays for headcount regardless of output. Slow weeks, ramp days, scope-clarification cycles, blocked work — all paid at full rate. The customer's invoice is bounded by team size, not shipped value.
- Idle capacity is the customer's problem. When the customer's product team can't feed the dedicated engineering team work fast enough, the team sits at low utilization while the bill keeps coming.
- Headcount commitment is sticky. If priorities shift, the customer either keeps paying for unused team or absorbs change-management cost to wind down. Refundable unused capacity isn't a thing.
- Quality varies with team composition. Customer pays the same whether the team is performing well or poorly. The vendor's incentive to maintain quality is reputation-based, not economic.
What all three models share
Each model has a different specific failure mode, but they share an underlying structure: customer pays for input (time, scope estimate, headcount) instead of output (shipped, accepted work). When pricing is anchored to input, the vendor's economic interest diverges from the customer's outcome interest. Each model handles the divergence differently — T&M optimizes for billable hours, fixed-price optimizes for completed scope at any quality level, dedicated teams optimize for sustained billable headcount — but none of them aligns vendor incentive with customer success.
The legacy pricing market evolved by adding wrappers (milestone billing on T&M, change orders on fixed-price, sprint reporting on dedicated teams) without changing the underlying input-priced primitive. The wrappers help at the margins; they don't fix the structural misalignment.
The outcome-based fix
Outcome-based delivery via Delivery Units inverts the pricing primitive. Instead of paying for engineer time, scope estimates, or headcount, the customer pays per shipped, accepted unit of cognitive output. The vendor's economic interest becomes shipping faster — more DUs delivered through the same talent capacity over time.
Three structural properties make this work:
- DU consumption only on acceptance. A DU consumes from the customer's wallet only when the corresponding work ships and acceptance criteria are met. Work in progress doesn't consume. Failed-acceptance work doesn't consume. The engine cannot bill for unshipped work.
- Refundable unused DUs. DUs sitting in the wallet — not allocated to active in-progress work — refund at the rate paid. The customer can recover budget for unallocated capacity at any time.
- Re-delivery on acceptance miss is platform-funded. If delivered work fails the customer's documented acceptance criteria, AiDOOS re-delivers at no additional DU cost. The customer never pays twice for the same outcome.
These mechanics cannot be retrofitted onto T&M, fixed-price, or dedicated-team pricing. They are properties of an output-priced model. Outcome-based delivery is structurally outcome-based; the legacy models can claim outcome alignment but cannot deliver it at the engine level.
The four-way comparison
| Dimension | Time & Materials | Fixed-Price | Dedicated Team | Outcome-Based (DU) |
|---|---|---|---|---|
| Customer pays for | Engineer hours | Defined scope | Headcount × time | Shipped, accepted DUs |
| Vendor incentive | Bill more hours | Ship cheap, claim done | Sustain billable headcount | Ship faster (more DUs) |
| Scope-change handling | Add hours | Change orders (slow) | Add team or extend | Consume DUs differently |
| Bench tax | Customer pays | N/A (fixed price) | Customer pays | Platform absorbs |
| Ramp tax | Customer pays | Vendor risk-prices it | Customer pays | Platform absorbs |
| Quality-vs-deadline trade | Open-ended (more hours) | Cuts corners on quality | Open-ended (more time) | Re-delivered on miss |
| Refunds for unused capacity | None | None | None (sunk monthly) | Refundable unused DUs |
| Outcome accountability | Customer's responsibility | Limited to scope statement | Customer's responsibility | Platform's economic interest |
| Best fit | Open-ended discovery work | Cleanly defined deliverables | Long-running stable scope | Most modern software work |
How to choose — decision framework
Start with the structure of the work, not the pricing model:
If scope is genuinely undefined and exploratory
You're doing discovery work where the team needs to figure out what to build through the work itself (early-stage R&D, novel research, ambiguous problem statements). T&M can fit because outcome can't be specified up front. But even here, smaller exploratory engagements often fit AiDOOS Starter ($2K, 10 DUs) for the discovery phase, then transition to outcome-based delivery once scope clarifies.
If scope is fully defined and stable
Rare in modern software. If it's genuinely true (rare integration with a stable third-party API where the spec doesn't change), fixed-price can fit. But verify the assumption — most "fully defined" scopes shift within the first sprint of work.
If you need long-running stable headcount
Dedicated team can fit for multi-year ongoing platform engineering with predictable load. Below that horizon (and more common in modern software), outcome-based delivery with the right tier (Scale or Enterprise) provides the same stability with refundable unused capacity.
If scope evolves and you want shipped-output accountability
Outcome-based delivery via Delivery Units. This covers the majority of modern software engagements: builds, modernizations, transformations, integrations, SaaS implementations, AI-enablement work. The DU economics absorb scope evolution at the engine layer; the customer pays for shipped, accepted work; unused DUs refund.
Worked example — same scope, four pricing models
A 6-month, 4-engineer modernization engagement. Scope: extract two services from a Rails monolith, migrate a database, ship the cutover. Mid-scope complexity, with some scope evolution expected.
T&M cost
- $80/hour blended × 4 engineers × 160 hours/month × 6 months = $307,200 base
- Customer-side management: 32 hours/month × $200/hour × 6 months = $38,400
- Ramp tax (months 1-3, 30% velocity gap): $46,080
- Bench tax + scope-change overhead: $30,000
- True 6-month TCD: ~$421,680
Fixed-price cost
- Vendor quote (with 30% risk premium): $400,000
- Change orders for scope evolution: $50,000-$120,000
- Customer-side management: $38,400
- True 6-month TCD: $488,400-$558,400
Dedicated team cost
- 4-engineer offshore team at $7,500/engineer/month average × 6 months = $180,000
- Customer-side management: $38,400
- Ramp tax (offshore engagements typically longer ramp): $54,000
- Idle capacity absorption (when scope-clarification cycles occur): $20,000
- True 6-month TCD: $292,400
AiDOOS outcome-based cost
- Scale tier (300 DUs / $40,000) — typical 6-month modernization at this scope
- Customer-side management: 6 hours/month × $200/hour × 6 months = $7,200
- No ramp tax, bench tax, or scope-change overhead
- True 6-month TCD: ~$47,200
The economic gap is not subtle. Headline rates lie; TCD framework normalizes the comparison.
FAQ
Isn't fixed-price still better for budget predictability?
Apparently better. In practice, fixed-price contracts almost always end with change orders that blow the original budget, plus the upfront 25-40% risk premium baked into the quote. Outcome-based delivery with a Scale or Enterprise tier provides the same budget visibility (DUs × $/DU = total) with structural protections against the change-order trap.
Can vendors offer outcome-based pricing on top of T&M?
Many claim to. What they actually offer is T&M with milestone bonuses or penalties — the underlying billing is still hours × rate, with a small variable component at milestone gates. AiDOOS DU pricing is structurally different — the engine itself cannot bill for unshipped work.
What about the small percentage of work that genuinely is open-ended discovery?
True open-ended discovery (early-stage research, novel problem definition) is sometimes a real T&M fit. But scope this carefully — most "discovery" engagements are actually ambiguous-scope engagements that benefit from outcome-based delivery with explicit DU caps (e.g., "first 20 DUs of discovery work, then re-scope based on learnings"). The discipline forces the work to surface a deliverable.
Does outcome-based delivery work for very large programs?
Yes — Enterprise tier with custom DU commitment scales to multi-million-DU programs. The mechanics (consumption on acceptance, refundable unused, re-delivery on miss) work the same regardless of scale; the rate compresses below $140/DU at Enterprise volume.
Where to start
If your engagement is open-ended discovery, T&M may fit. If your scope is genuinely fully defined and stable, fixed-price may fit. If you need long-running stable headcount, dedicated team may fit. For everything else — which is the vast majority of modern software engagements — outcome-based delivery via Delivery Units is structurally better economics.
Schedule a call to walk through your scope. For deeper coverage of the operating model, see Outcome-Based Delivery and Delivery Units. For the broader cost-comparison framework, see Total Cost of Delivery. For terminology, see the AiDOOS glossary.