Fixed price vs time and materials: which contract to sign

Fixed price isn’t a discount. It’s insurance, and you pay the premium. A fixed bid moves estimation risk from your side of the table to the vendor’s, and the vendor prices that move. Commonly a buffer in the region of 15 to 30 percent sits inside the number, and you pay it whether or not the risk ever lands. Time and materials leaves the risk with you and costs less when the work goes well. So the real question isn’t which model is cheaper. It’s whether your scope is settled enough for anyone to price it honestly.

We sell fixed scope. Read what follows as testimony from a hostile witness: the half of the argument that runs against our own book, including when to refuse a fixed quote from us.

One distinction runs underneath the whole argument, so it is worth stating before the argument starts. The bands published on our services pages, and named again further down this piece, are estimates in US dollars, not quotations; the quote that follows scoping is fixed in writing before kickoff. An indicative range and a number you can sign are different objects, and almost every complaint about published software pricing is really a complaint about the two being presented as one.

What you are actually buying when you buy a fixed price

Three things, and only one of them is code. A number you can take to a board without a range attached. A date. And a transfer of estimation risk: if the payments integration takes three weeks instead of one, that’s the vendor’s problem rather than a conversation about your budget.

The third item is the one with a price on it. Nobody absorbs unbounded downside for free, and a firm that appears to be doing so is either mispricing the work or planning to win the money back through change orders.

How the buffer gets sized

A competent estimator builds the work up task by task, then adds contingency in proportion to what they don’t know. Our own working bands, stated as ours: roughly 10 to 15 percent on work the team has shipped many times with settled inputs, and 25 to 40 percent where a third-party integration, an unseen production dataset, or an unnamed compliance reviewer sits inside the scope.

The buffer also compounds. Task estimates get padded, then a project-level contingency lands on top of the padded total. And it covers more than engineering risk: it prices in the client who takes nine days to answer a blocking question. That part is the cheapest for you to remove.

What shrinks the buffer

Four artefacts do most of the work. Hand them over before the estimate, not after.

• A settled data model. The entities, the relationships between them, and which system holds the source of truth for each field. A document that could become a migration file in a day, rather than the migration file itself.
• A decided auth story.The distance between “users log in” and “enterprise SSO over SAML, with SCIM provisioning and role inheritance across tenants” is weeks of work, and the sentence in your brief is almost always the first one.
• Designs that exist. Not a moodboard and not three reference sites. Screens, plus the empty state, the error state, and the narrow breakpoint. An undesigned screen is estimated as the average of everything that word could mean.
• Integration endpoints with credentials in hand. Sandbox access to the CRM, the payment processor, the ERP, before the quote is written. An integration described in prose is priced as risk. One whose sandbox the estimator has opened is priced as work.

Then run the test that tells you who you’re dealing with: supply those four things and ask for a re-quote. If the number doesn’t move, the buffer was never contingency. It was margin. The same inputs swing an early-stage estimate around, which we took apart in what building an MVP actually costs.

What time and materials actually costs you

The buffer disappears and the risk comes home. You pay for hours worked, so when the estimate turns out to have been pessimistic you keep the difference. That’s why buyers with their own technical leadership tend to prefer it.

The failure mode isn’t the overrun. It’s drift. A fixed bid contains a forcing function: somebody has to say no, and the contract says who. Under time and materials the work continues because it can, and three months later nobody can point at the decision that added the third dashboard. T&M fails quietly, in a burn report nobody reads.

The controls that make time and materials safe

Five, and they belong in the agreement, not in an onboarding call.

• A not-to-exceed cap, with written notice at 70 and again at 85 percent of it. A cap you first hear about on the day it’s reached is a surprise rather than a control.
• A weekly burn report by workstream, not a monthly invoice by headcount. Hours attached to features are reviewable. Hours attached to names are not.
• A fixed commitment per increment, so the flexibility lives between two-week blocks instead of inside them.
• Termination on two weeks’ notice, with the code in your repository and CI in your cloud account from the first commit.
• A rate card fixed for the term, with named individuals and notice before anyone is substituted. Silent substitution is how a senior quote becomes a junior team, one of the failures we set out in our comparison of in-house, agency and freelance delivery.

The change order clause is where a fixed price lives or dies

Buyers read the price and the timeline. The clause that decides how the next six months feel is the one about changes, and it’s the one that gets skimmed.

The predictable failure: small requests arrive, nobody wants to invoice for twenty minutes, so they get absorbed, and absorption eats the buffer. Once it’s gone the vendor starts refusing things, including reasonable things, and a client told yes for two months reads the first no as bad faith. Neither party did anything wrong. The contract never named a mechanism.

What a good scope exclusion looks like

A bad exclusion is a catch-all: “excludes any work not described above.” It reads as airtight and decides nothing, because the argument you’ll actually have is about whether a thing was described above. A good exclusion is specific, testable, and says what happens if you want the excluded thing anyway. As an illustration of the shape, not a quote from anyone’s contract:

Authentication is email and password with a reset flow. SSO (SAML or OIDC), SCIM provisioning and directory sync are excluded. If required, they are quoted as a change order at the attached rate card and are estimated to add two to three weeks to the schedule.

Both sides now know the shape of the door before anyone walks through it. The same treatment belongs on the browser matrix, on data volume (“the importer assumes CSV files up to 50,000 rows; larger files are a streaming importer and different work”), on who writes the copy, on third-party licence fees, and on the load the system is built to hold.

The sentence that destroys a fixed-price relationship

“…and any reasonable minor amendments.” Also “minor revisions as required”, “a reasonable number of rounds”, and “to the client’s satisfaction”. Every one is unbounded and undefined, and the two parties define it differently on the precise day it matters. The client reads a promise. The vendor reads typo fixes. Neither is lying, and there’s nothing in the document to appeal to.

Replace it with something countable. Two rounds of revision per screen, each round delivered as one consolidated list within five working days, further rounds billed at the rate card. Less pleasant to read, and enormously easier to live inside. A vendor who resists making it countable is protecting their ability to argue about it later.

The mechanics to write down

Five lines. They fit on half a page.

• Who raises and who approves.Named roles both sides, and a rule that a change without the named approver isn’t a change.
• Turnaround. The vendor responds within a stated number of working days with cost, schedule impact, and anything the change breaks downstream.
• Price basis.The rate card is fixed for the project term, so a change order cannot be priced opportunistically once you’re committed and the code is half written.
• Schedule stated separately from cost. A change adding $4,000 and two days is a different decision from one adding $4,000 and three weeks. A blended number hides which you are approving.
• A running decision log. Request, decision, date, cost, approver. Most late disputes on fixed-price work are memory disputes, and a shared log ends them in ninety seconds.

Three clauses to read before you sign either model

Acceptance, and the acceptance clock

A deliverable should be deemed accepted if it has not been rejected in writing inside a fixed window (five working days is normal), with the rejection citing specific written criteria. Without a clock, one stakeholder on holiday suspends a payment indefinitely. Without written criteria, “it doesn’t feel right” is a valid rejection, and the definition of done belongs to whoever is most confident in the room.

IP assignment, and what triggers it

Read whether intellectual property transfers on payment or on delivery. On payment is normal and defensible. What matters more is what you hold in the meantime: the repository in your organisation, the cloud account in your name, the domain on your registrar, from the first week.

If the only copy of your codebase lives on the vendor’s infrastructure until the final invoice clears, you haven’t bought software. You’ve bought a position in a negotiation you didn’t know you were in. We push to the client’s repository from the first commit on web platform and application work.

Termination, and what leaving costs

You want termination for convenience with notice, and what you owe on exit should be work completed plus work genuinely in progress. Some fixed-price agreements quietly claim the remaining contract value instead. Then name the handover as a deliverable: repository access, deployment documentation, credentials, and a call with the engineers who wrote it. State whether it’s included or billed. It’s the cheapest insurance in the document.

Milestone-based payment: tie money to behaviour, not phases

Milestones named after phases are unfalsifiable. “Design complete” and “development complete” are assertions, not tests, and arguing about whether they happened is the argument the milestone was supposed to prevent.

A milestone should be a demonstrable behaviour on a URL you can open. As an illustration: a user can sign up, create an organisation, invite a second user, and both accounts see the same project list, on staging, today. Either that’s true or it isn’t.

Our own practice on sizing, offered as ours rather than as a standard. On a project in the band our published rate card calls fixed scope, which starts at $7,500 with most landing between $18,000 and $45,000, we bill half on contract and half on delivery up to about $30,000, and move to three to five milestones above that. No more than five, because a twelve-milestone schedule on a three-month build is theatre both sides abandon by week four. Hold at least 20 percent to final acceptance; a closing tranche under about 10 percent stops working as leverage, which is the only reason it exists.

Retainer versus project is a different question entirely

These get compared as rival billing models for the same work. They are not. A project buys a defined outcome and ends; a retainer buys capacity for a system that’s already live. Our published rate card puts retainers from $2,500 a month and fixed-scope projects from $7,500, but price is not the deciding input. Whether the work has an end is. If it does, buy a project: a retainer finishes it more slowly and with less pressure on anyone.

Retainers rot when nobody reviews them. Ask for a one-page monthly note listing what shipped, and set an explicit renew-or-stop decision at ninety days. A retainer nobody has audited in a year is a subscription you keep paying out of habit.

When a fixed price from us would be the wrong thing to buy

This is the section that costs us work.

If discovery hasn’t happened, our fixed price is fiction with contingency stapled to it, and you pay for our ignorance rather than we do. Decline a fixed bid, ours included, while any of these is open. No agreed data model. No decision on authentication. No designs. No credentials for the systems the build must integrate with. A stakeholder with veto power who hasn’t yet seen anything.

In that state a fixed price hurts you twice. You pay the fat end of the buffer, and you create a vendor financially motivated to read every ambiguous line of the scope narrowly, at exactly the moment you need it read generously. That incentive is structural rather than a comment on anybody’s integrity, ours included.

The alternative is a small, paid, bounded discovery step that produces the four artefacts above, after which a fixed bid becomes honest. Our published scoping sprint is $3,500 for a week, credited in full against a build that starts within thirty days, and exists for this, as part of how we scope and de-risk a build before quoting it. If you’d rather not buy that from us, buy it elsewhere or write it yourself over a fortnight. The artefacts are the point, not the invoice.

And the case for buying nothing at all: if you can’t describe in one sentence the single workflow that has to work on launch day, no contract shape rescues you. Fixed price locks in the wrong build. Time and materials funds the search for the right one at full rate. Our published minimum for a build is $7,500, which isn’t a small enough number to spend finding that out.

How to avoid scope creep without becoming your vendor’s adversary

Scope creep is rarely malice. It’s a missing forum: several people each asking for something small, through several channels, with nowhere for the requests to be seen together.

Two mechanisms handle most of it. A parking lot both sides can read: every out-of-scope idea goes in with a date and a requester, nothing is refused, only deferred somewhere visible, and at the end of each increment you promote at most one item with a change order attached. Then one named approver, rather than a committee or whoever emailed most recently. The best predictor of a calm fixed-price project we’ve seen is whether one person can say yes and have it stick.

A rule we hold ourselves to, stated so the trade is visible: if a request takes under an hour and doesn’t touch the data model, we do it and record it in the weekly note. That’s arithmetic rather than generosity, since invoicing eighty dollars costs more in goodwill than it collects. It has a ceiling, because “we’ll just do it” without one is how a fixed-price project becomes a loss, and a loss becomes an argument.

The compressed decision

Buy fixed price when the data model is settled, authentication is decided, designs exist and integration credentials are in hand. Buy it knowing you paid a premium for a number that doesn’t move. Buy time and materials when any of those is open, and only with a cap, a weekly burn report by workstream, and a two-week exit.

Whichever you sign, spend the review time on the exclusions, the change order clause and the acceptance criteria rather than the headline figure. That’s where the money actually moves. The five builds we publish sit on our work page, all of them real, two of them ours and three contracted. And if the scope isn’t settled, say so when you send us the brief. The answer may be that you should buy discovery first, from us or from anyone.