Buyers tend to arrive with a preference. Procurement teams want a fixed price because it is a number they can approve. Product teams want time and materials because they know the scope will move. Both are right about their own risk, and the argument between them is really about who carries which uncertainty.
This article sets out what each model protects you from, what it exposes you to, and the questions we ask before recommending one. It ends with the arrangement most product builds settle on, which is neither in its pure form.
What fixed price does
A fixed price buys a defined scope for a defined sum. The vendor carries the estimation risk: if the work takes longer than planned, the vendor absorbs it. In exchange, the scope has to be written down in enough detail to price, and anything outside it is a change request with its own price and its own effect on the date.
It works when the scope is genuinely known: a website with agreed pages, an integration with a documented API, a module with a specification that has already been reviewed, or an MVP whose discovery has produced a scope document everyone has signed.
It fails when the scope is a wish list. The vendor prices the uncertainty in, so you pay for risk that may not materialise, and every clarification becomes a negotiation. The tell is a proposal with many assumptions and exclusions; those are the places the price will move.
What time and materials does
Time and materials buys people at agreed rates for the time they spend. You carry the estimation risk and get the flexibility in return: reprioritise every sprint, add a feature without a change order, stop when the value is delivered. The vendor's obligation is to staff the team as agreed and to show the work.
It works for evolving products, research-heavy work such as AI features where the approach is found by trying things, and long-running engagements where a backlog is set sprint by sprint.
It fails when nobody on your side owns the backlog. Time and materials without a product owner is a team waiting for decisions at an hourly rate. It also fails when the vendor's reporting is thin; you cannot manage what you only see in an invoice.
The questions that decide
We ask these at the end of discovery, and the answers usually point one way.
Can the scope be written down today? If a competent engineer could read the scope document and build the thing without asking a strategic question, fixed price is available. If the document has more open questions than decisions, it is not.
How much will change in the first three months? Be honest. A product entering a market for the first time changes; an internal replacement for a known process does not.
Who decides, and how fast? Fixed price needs a client who can approve a change request in days. Time and materials needs a product owner who can keep a backlog ordered every week.
What does the budget approval look like? Some organisations can approve a capped time and materials budget with a not-to-exceed figure; others can only approve a fixed sum. That constraint is real and it is fine to design around it.
What happens if it is late? With fixed price the vendor eats the overrun but may cut quality to do it, which is why the acceptance criteria matter more than the price. With time and materials you pay for the overrun but keep the quality bar, which is why the reporting matters more than the rate.
The hybrid most builds use
The arrangement that works for most product builds is in two parts.
First, a fixed-price discovery: two weeks with a written scope, an architecture note, a risk register and an estimate at the end. The price is small, the deliverables are concrete, and you can take them to any vendor.
Then either a fixed price for the first release, now that the scope exists, or time and materials with a not-to-exceed cap for the release and for what comes after. Change requests on the fixed portion are priced against the same day rates, so the two halves reconcile.
The third model, a dedicated team, is time and materials with a monthly fee per named person instead of hourly billing. It suits ongoing development where you want engineers who stay on the codebase. Each of the models is compared side by side on the engagement models page, with what you get under each, and the custom software development page shows what a build looks like under any of them.
What to put in the statement of work, whichever you choose
The model matters less than the document.
At Tankar every model runs through the same six-stage process, with a weekly demo, a shared board and the code in your repository from the first week, so the difference between the models is only who carries the estimation risk, not how the work is done or how much of it you see.
A short way to decide
If you can describe the finished thing in a page, ask for a fixed price. If you can describe the first month but not the third, ask for a fixed-price discovery and decide the rest at the end of it. If you already know the backlog will move every week and someone on your side owns it, ask for time and materials or a dedicated team, and insist on the reporting that makes it manageable.
