Pricing FDE projects: fixed price, T&M, and outcome-based contracts. Who bears the risk?

Procurement typically receives three FDE proposals on the table. One quotes a fixed project price at $480K, another quotes $2.4K per person-day billable as spent, and a third quotes a base fee plus a success share once adoption hits targets. The numbers don't line up for direct comparison because each vendor is selling something different. When selection stalls here, the real issue often isn't budget. It's not knowing which of these pricing models actually puts the risk of failed adoption back on the vendor.

Fixed price, T&M, and outcome-based models handle different risk profiles. Each has specific use cases and pitfalls worth understanding.

How the three FDE pricing models work

Fixed price packages the entire delivery scope into a single contract total. Once signed, the vendor absorbs any overages in time or headcount. This seems safest for the buyer, but it requires scope to be fully frozen upfront. In AI implementations, scope is where the most uncertainty lives. How many data sources should the RAG system integrate? How many workflows should the Copilot cover? These questions often don't surface until halfway through build. When scope does shift (and it usually does), you're issuing change orders, adding budget, and extending the timeline.

T&M (Time & Materials) charges by person-days actually invested, so you pay for what you use. This model openly accepts that requirements will shift, making it practical for exploratory work. The trade-off is that the buyer carries all risk. Work that moves slowly or misses the mark still gets paid. Without clear acceptance criteria, the commitment becomes open-ended.

Outcome-based ties part of the vendor's fee to measurable results. Not just that the system shipped, but whether monthly active coverage hits X percent or manual processing hours drop by Y percent. This model puts adoption risk directly on the vendor. It requires a clear answer to a single question: is anyone actually using this?

Why adoption should be in the contract

This happens often: a fixed-price project closes when the system passes acceptance testing. Features complete, both parties sign off, final invoice paid. Three months later, actual usage is in single digits. Technically the vendor hasn't breached the contract. It specified delivery of a system, not adoption of one.

This is why FDE exists as a discipline. A working demo isn't the goal. The goal is adoption. Contracts without adoption in their acceptance criteria are structurally designed to end at handoff. They push the most difficult work (the last mile) onto the buyer.

Outcome-based pricing matters not because it's cheaper, but because it requires both sides to define success before signing. To tie payment to results, you must establish upfront what gets measured, how it's measured, what timeframe applies, and who validates. This conversation tends to surface vendors unwilling to stay engaged after handoff.

How it works in practice: mixing models

Most projects don't stick with a single model throughout. A common approach is phased: T&M during exploration to validate uncertainty with a PoC, then fixed price for the main delivery once scope settles, then outcome-based compensation for post-launch adoption metrics.

Each model addresses what it does best. T&M provides flexibility, fixed price provides cost certainty, and outcome-based ensures accountability. None carries the full burden alone.

For procurement: ignore the total price and ask each vendor one specific question. If nobody uses the system three months after launch, does your compensation decrease? If the answer is no, the risk has shifted to you.

Adoption metrics belong in contracts, not pitch decks. The goal of engineering isn't shipping a working system but ensuring it survives in the buyer's actual workflow. That's the work we focus on, so we tie part of our fees to whether adoption actually happens.