Fixed price vs time and materials: which contract actually works for custom software
A non-technical founder’s framework for picking the right contract structure with a software partner, and the clauses that make T&M billing accountable.
The first time a founder forwards us two contract drafts and asks which one to sign, we already know how the conversation will go. One draft is fixed price: a single number, a list of features, a delivery date. The other is time and materials: an hourly or weekly rate, a soft estimate, a request for trust. The founder has been told fixed price is safer because it caps the bill, and they want us to confirm.
Most of the time we tell them the opposite. For early-stage custom software, time and materials with a milestone-gated structure is the better default. Fixed price wins in a narrow set of cases that usually do not apply, and when it does win, you have to pay extra to make it honest. The contract you sign for custom software is not a financial instrument. It is the operating system for the relationship you are about to build.
This is the framework we walk founders through before they sign anything.
What each contract actually is
Fixed price means you and the vendor agree on a fixed total amount for a defined scope of work, paid against milestones. The vendor takes the delivery risk. If they underestimated, that is their problem.
Time and materials, often shortened to T&M, means you pay for the time the team actually spends, usually billed by the week or by the sprint, at agreed rates. The vendor sends an invoice for hours worked. You take the delivery risk. If the work runs longer than expected, the bill keeps running.
That is the textbook description. It is also where most articles on this topic stop, and it is why founders sign the wrong contract. The two structures look symmetrical on paper. In practice they create completely different incentives, and those incentives shape the product you end up with.
The four conditions that make fixed price honest
Fixed price is not a bad structure. It is a structure that requires conditions most early-stage software projects cannot meet. When all four of these are true, fixed price can be the right call.
The scope is genuinely known. Not “we know we want a marketplace.” Known means: the screens are designed, the integrations are listed, the edge cases are documented, the data model is settled, the rate at which the customer changes their mind is near zero. If you cannot hand a stranger a folder and have them estimate it the same way your vendor did, the scope is not known.
The work is a commodity. A WordPress site for a marketing brochure, a Shopify theme tweak, a known-shape mobile app for a known-shape business. Things that have been built thousands of times, where the vendor has a real frame of reference. The further you are from a commodity build, the more padding the vendor needs in the fixed number to absorb the unknowns. That padding is the price you pay for risk transfer.
You will not change your mind. If the only person who can change scope is you, and you can credibly promise not to, fixed price stays clean. The moment you change scope, fixed price becomes a series of change orders, each negotiated under information asymmetry. By the third change order, the contract has stopped working.
The vendor has built this exact thing recently. Not “something like this.” This. A team that has shipped the same shape of product for two prior clients can quote a fixed price honestly because their estimate is grounded in two prior quotes that were right. A team that is new to the domain is guessing, and their guess is loaded with risk margin.
If you cannot defend all four points to a peer, fixed price is the wrong structure for your project. The number on the contract is fiction.
The four ways fixed price usually breaks
Founders who sign fixed price contracts on real custom software almost always end up in one of these failure modes.
The vendor padded the number, and you overpaid for risk you never realized. A good vendor knows that “build us a SaaS for property management” carries unknown unknowns. They quote the number that lets them sleep at night. If everything goes smoothly, you have just paid a 30% to 60% premium for the privilege of certainty. That money would have gone further on a T&M project that ended at the same place.
The vendor underestimated, and now they are losing money on you. Fixed price aligns nobody’s incentives once a project goes underwater. The vendor’s only path back to margin is to cut corners: skip tests, copy code from a previous client, ship something they would not be proud of, push a junior developer onto a senior problem. You do not have visibility into any of this until the product breaks in production six months later.
Scope creeps, and the relationship collapses. Real software discovers itself as it gets built. A founder sees the second prototype and realizes the PRD they wrote at the start was wrong. Under fixed price, every new realization becomes a contract negotiation. The vendor turns into a clipboard. You start hating each other before the MVP ships.
The vendor disappears at 80% done. This is the worst failure mode and the most common. Fixed price means most of the cash flow is back-loaded against late milestones. When the vendor has already collected the bulk of the easy work and the remaining scope is the hard, ambiguous part, walking away is rational for them. We have seen this happen at three different software houses with three different founders. The pattern is identical: a great kickoff, weekly demos that look good, and then a quiet decline in attention starting around month four.
We have written more about how to vet the software house signing this contract before any contract structure matters. A bad partner will fail you on either contract. The contract structure makes the failure faster or slower. It does not change the ceiling.
Why T&M is the default for custom software
Time and materials is unfairly maligned because it sounds like a blank check. In a healthy structure, it is the opposite.
T&M aligns incentives where they should be aligned. The vendor is paid to ship working software each sprint. You are paid in the form of working software each sprint. Nobody is in a position to lose money on you, so nobody is in a position to cut corners on you. When scope changes, the conversation is “this will add two more weeks” and not “this triggers a contract amendment that will take three weeks to negotiate.” Decisions get made faster. The product gets better.
T&M also exposes the truth of the work to you. You see the hours, the velocity, the trade-offs. Inside a fixed price project, the vendor is incentivized to keep you out of the engineering reality, because every conversation about reality becomes a renegotiation. Inside a T&M project, the vendor is incentivized to bring you into the engineering reality, because that is how you stay confident that the bill is fair.
There is a real cost. T&M means you carry the budget risk, and the budget can run. The way to neutralize that risk is not fixed price. It is a T&M structure that bakes in accountability.
The T&M contract structure that doesn’t bleed you
Most T&M contracts are too loose. The vendor sends a weekly invoice, the founder pays it, and three months in nobody has a clean view of what was actually delivered. We use a more disciplined structure with every founder we work with. It has five clauses, all of which are negotiable, none of which are exotic.
Cap per sprint. Set a maximum number of hours per week or per sprint. The vendor cannot bill above the cap without a written agreement, and overages do not roll over. This is a soft ceiling that keeps the team focused on shipping the most valuable thing each cycle, instead of grinding hours on whichever ticket is open.
Demo-or-no-bill. Every sprint ends with a working demo of what was built. If the demo does not happen, that sprint is not billable. The clause sounds aggressive in the negotiation. In practice it is what every honest vendor does anyway, and the formality protects you against the one in five engagements where the team starts skipping demos around month three.
Right to pause at any milestone. You can stop the project at the end of any sprint with no penalty, no kill fee, and no clawback. You owe for hours already worked. That is it. This is the single most important clause in the contract. It turns the relationship into a sequence of small bets, each one re-validated by what the previous sprint actually shipped.
Code in your repo from day one. The codebase lives in your GitHub or GitLab organization, not the vendor’s. Every commit pushed by the team is yours immediately, not at the end of the project. We have walked into too many situations where a founder discovered, during a vendor breakup, that they did not own the code their company runs on. This clause makes that breakup mechanically possible.
A decisions log, not a status report. The vendor maintains a short, written log of the decisions made each sprint and the trade-offs behind them, in your repo. Not a status update on tickets closed. A record of “we picked Postgres over MongoDB because of X,” “we deferred the multi-tenant work because of Y.” The log is what lets a future engineer, including the one who replaces this team, understand why the system looks the way it does. It is also what makes the eventual handover survivable.
A T&M contract with these five clauses gives you most of the safety of fixed price, almost none of its incentive damage, and a level of visibility into the work that fixed price actively hides from you. We call this the milestone-gated T&M and we ask every founder to negotiate for it before any work starts.
When to actually pick fixed price (and what to pay extra to make it real)
There is a narrow case for fixed price even on real custom software. It applies when you have a hard external deadline that the vendor cannot miss, the scope is unusually well-defined, and the vendor has built this exact shape of thing before. A regulator-imposed go-live date, a flagship customer integration with a contractually fixed start date, a demo deck for a board meeting that has already been scheduled.
In those cases, fixed price is not really about saving money. It is about buying delivery insurance. To make that insurance honest, three things need to be true.
The vendor builds in a real risk premium, and you accept it. If the quote feels suspiciously low for fixed price, walk away. The vendor either does not understand the work or is planning to cut corners.
You pre-negotiate the scope-change protocol before signing. Not “we will figure out change orders as they come.” A written process that says: a change order under X dollars is approved by email; above X dollars it triggers a 48-hour pricing window and a re-baselining of the timeline. This makes the inevitable scope changes manageable rather than relationship-ending.
You keep at least 25% of the contract value in the final milestone, payable only on full delivery and an agreed acceptance test. This is the lever that prevents the 80%-done walkaway. The number you keep at the end is what the vendor cannot afford to leave on the table.
If you cannot get all three of those, the fixed price contract is theatre. Switch to milestone-gated T&M and stop negotiating against yourself.
Quick FAQ
What is the difference between fixed price and time and materials in plain language?
Fixed price is a single number for an agreed scope. Time and materials is the meter running on the actual time the team spends. The vendor takes the delivery risk on fixed price. You take the budget risk on T&M, and you can neutralize most of it with the right clauses.
What is the difference between fixed price and a fixed-fee retainer?
A retainer is a recurring fixed fee for a recurring scope of work, usually ongoing rather than tied to a specific deliverable. It is closer to T&M with a cap than to a project-shaped fixed price. Retainers work well after the first version of the product is live, when the team is iterating instead of building from zero.
Is hybrid possible?
Yes, and it is sometimes the right answer. The most useful pattern we see is a small fixed-price discovery phase (two to four weeks, scoped to producing a written architecture and a signed-off product spec) followed by milestone-gated T&M for the build. The discovery is cheap, the scope is genuinely known by the end of it, and you start the real work with a vendor who has already proven they can listen.
Who decides which one we sign?
You do, not the vendor. Vendors prefer fixed price when they are trying to lock in revenue and T&M when they think the scope is going to grow. The right structure is the one that fits the project, not the one that fits the vendor’s quarter.
Should the contract type change as the company grows?
Probably. Early-stage custom software, where the product is still being discovered, almost always wants milestone-gated T&M. Once a system is in production and the team is iterating on a known shape, fixed-price retainers can work well. The contract is a tool, not an identity.
The contract is the relationship. Pick the one that lets you build the thing you actually want, with the people you actually trust. Then negotiate the clauses that make either structure honest. The number on page one matters less than the five lines on page seven.