Fixed Price vs Time & Materials vs Dedicated Team: Which Contract Model Fits Your Project?

By the time a buyer asks us "do you work fixed price or time and materials?", they are usually asking something else: who carries the risk if this project turns out to be harder than we both think? That is the real question, and the three standard contract models answer it in three different ways.

This is a practical comparison — what each model optimizes for, where each one quietly fails, and how to tell which one fits the project in front of you. If you are still at the budgeting stage, start with our breakdown of custom software development costs in Vietnam and come back to the contract question once you have a range.

The three models at a glance

	Fixed price	Time & materials	Dedicated team
You pay for	A defined scope	Hours actually worked	Team capacity per month
Risk sits with	The partner	The client	Shared
Needs upfront	A locked, detailed spec	A clear direction and an engaged product owner	A roadmap and ongoing priorities
Change is	A change order	Just the next ticket	A re-prioritization
Best for	Well-understood, bounded builds	Discovery, R&D, evolving scope	Long-horizon products and platform ownership
Typical horizon	4–16 weeks	Rolling	6+ months

Fixed price: buying certainty, paying for it in flexibility

Fixed price is the model most procurement departments prefer, and for good reason: one number, one scope, one delivery date. It converts a technology decision into a budget line, which is exactly what a board or a tender committee needs.

Where fixed price genuinely works

The scope is genuinely knowable. A migration with a documented source system. A portal with a published requirements standard. A second phase of something already live.
The requirements will not move. Regulatory deadlines, tender specifications, and integration contracts are stabilizing forces — they hold scope still.
Accountability needs to be unambiguous. In public-sector and enterprise procurement, "the vendor carries delivery risk" is often a hard requirement, not a preference.

Where fixed price breaks

Fixed price prices uncertainty as contingency. When nobody knows exactly what is being built, that contingency is either too small (and the partner starts defending margin instead of building the right thing) or too large (and you overpay for risk that never materialized).

The failure pattern is predictable: three weeks in, someone learns something true about the users, the data, or the legacy system that should change the plan — and the contract makes the right decision expensive. Change orders become adversarial. Scope conversations replace product conversations.

Fixed price is excellent at protecting a budget and poor at absorbing new information. Choose it when the information is already in.

Time & materials: buying adaptability, paying for it in predictability

Under time and materials you pay for hours worked, usually against a monthly cap and a rolling backlog. Nothing is more honest for work whose shape is still forming — AI features, integrations against a poorly documented system, anything where the second week teaches you something the first week could not.

Where time & materials works

Discovery and prototyping, where the deliverable is a decision, not a feature.
AI and data work, where accuracy targets are only knowable after you have seen real data. See our notes on choosing between RAG and fine-tuning.
Integration-heavy builds, where every external system holds a surprise.

What it demands from you

Time and materials transfers risk to the client, so it only stays healthy when the client stays engaged. That means a real product owner with decision authority, a visible backlog, a weekly demo, and a burn report you actually read. Without those, T&M becomes an open tab — and that is the version of this model that earns outsourcing its bad reputation.

Dedicated team: buying capacity and continuity

A dedicated team is a monthly retainer for a named group of engineers who work only on your product. You are not buying a deliverable; you are buying the ability to keep deciding what gets built, with people who already understand your system.

This model earns its place when the product is a long-term asset rather than a project — a platform under continuous change, a system with compliance obligations that never end, or a roadmap that runs past the next twelve months. It is also the only model where institutional knowledge compounds instead of resetting at each contract boundary.

The trade-off is commitment: you carry the cost of capacity whether or not a given month is busy. Below roughly six months of continuous work, the overhead of forming the team rarely pays back.

The models are not mutually exclusive, and treating them as a single choice is the most common mistake we see in RFPs. In practice the sequence that protects both sides looks like this:

Phase 0 — fixed-price discovery (2–4 weeks). A small, capped engagement that produces the thing fixed price actually needs: a validated scope, an architecture, a risk register, and a defensible estimate. Cheap to buy, and it converts unknowns into knowns.
Phase 1 — fixed price per milestone. Now that scope is real, fix the price on bounded milestones with explicit acceptance criteria. You keep budget certainty where certainty exists.
Phase 2 — dedicated team or retainer. Once the system is live, continuity beats project accounting. Maintenance, iteration, and compliance work move to a standing capacity arrangement.

That is close to how we structured the MRB tender information portal and the MAUR portal: a bounded specification stage against a public transparency standard, milestone delivery, then ongoing custodianship of a system the public actually depends on.

Five clauses that matter more than the model

We have seen well-chosen models fail on bad paperwork, and awkward models succeed on good paperwork. Whichever you pick, get these five right:

Acceptance criteria, written before work starts. "Working software" is not a test. "The portal publishes a tender record conforming to the standard, and a named reviewer can verify it in the staging environment" is.
IP assignment on payment, including code, infrastructure-as-code, and design files. Ask specifically about the repository, the CI configuration, and the cloud account. Owning the code but not the pipeline is not ownership.
Change control with a price attached. A change process that is free is a process nobody uses. A written, quick, priced change path keeps changes honest.
Exit and handover. Documentation standard, runbook, credential transfer, and a defined support window after handover. Ask what happens in month 13.
Security and compliance obligations, named explicitly. Which standard applies — OWASP ASVS, PCI-DSS, GDPR, local data residency — and who is accountable for evidence at audit time. See our security engineering practice for how we scope this.

A decision shortcut

Specification is complete, deadline is external, and change is unlikely → fixed price.
You are still learning what to build, or the data is unproven → fixed-price discovery, then milestones.
The system is strategic, permanent, and will keep changing → dedicated team.
You cannot assign a product owner with decision authority → avoid pure time and materials. Without an engaged owner it will disappoint you.

Frequently Asked Questions

Is fixed price always more expensive than time and materials?

Usually it carries a contingency premium, because the partner absorbs the risk of an underestimate. Whether it costs more in the end depends on scope stability: if the scope holds, fixed price often costs slightly more; if the scope moves substantially, fixed price plus change orders can cost considerably more than time and materials would have.

How do I stop a time-and-materials engagement from running away?

Three controls do most of the work: a monthly spend cap that requires written approval to exceed, a visible backlog with weekly demos, and a burn report that shows hours against outcomes rather than against tickets. If any of the three is missing, the model is not being run properly.

What is a reasonable minimum commitment for a dedicated team?

Six months is the point where the model normally starts paying back, because the first four to six weeks go into context-building that you only amortize over time. For shorter horizons, milestone-based fixed price is usually the better instrument.

Can we change the model mid-engagement?

Yes, and well-run engagements often do — discovery under one model, delivery under another, maintenance under a third. Agree the transition points in the original contract so the switch is administrative rather than a renegotiation.

Which model is best for AI projects?

Start with time and materials or a capped discovery phase. Accuracy targets for AI systems are only knowable once you have run real data through an evaluation set, and fixing a price before that means one side is guessing. Once the accuracy target is proven, the surrounding product work can move to fixed milestones.

Choosing with us

We work across all three models and will tell you which one we think fits — including when the honest answer is a two-week discovery engagement rather than the six-month build you asked us to quote. If you are weighing an upcoming project, talk to us about scope and structure before the specification is locked; that is the point where the choice is still free.