Comparison · Costs & timelines

Fixed price vs time and materials: which contract a founder should pick, and when

Fixed price vs time and materials for software: who carries the risk, what each costs, the hybrids that work, and how to estimate development time first.

By Akash Bansal, founding engineerUpdated 5 November 20266 min read

Founders usually ask "fixed price or hourly?" as if it were a question about price. It's a question about risk: if the work takes longer than planned, who pays? Get that right and the rest of the contract follows. I quote fixed prices after scoping, and I'll explain why, but also when I'd tell you not to accept one.

What is the difference between fixed price and time and materials?

A fixed-price contract sets the price for a defined scope up front; if the work takes longer, the builder absorbs it. Time and materials (T&M) bills for the hours or days actually worked, plus expenses; if the work takes longer, you pay more. The difference is who carries the overrun.

The US government's procurement rules state it clearly. A firm-fixed-price contract "places upon the contractor maximum risk and full responsibility for all costs and resulting profit or loss" (FAR 16.202-1). A time-and-materials contract "provides no positive profit incentive to the contractor for cost control or labor efficiency", and should be used only when it isn't possible to estimate accurately at the time of contracting (FAR 16.601).

Fixed price vs time and materials: side by side

When is a fixed price contract the right choice?

When the scope can be written down and tested. For a founder building a first version, that's most of the time, as long as the scoping happens before the price. A fixed price on a written scope gives you three things T&M can't: a number you can raise money against, a builder whose incentive is to finish, and a natural conversation every time scope grows.

The research on estimation says when a fixed number becomes meaningful. Steve McConnell's Cone of Uncertainty white paper (Construx) notes that a commitment made at the initial-concept stage carries a 2x–4x error, and that meaningful commitments become possible once the project has done the work to narrow the cone, about 30% of the way in. That's the argument for a scoping step: it moves the commitment from the wide end of the cone to the narrow end.

It's why my own MVPs are quoted this way: a fixed quote after scoping, a written design doc, and working software every week so you can see the price turning into product.

When is time and materials better?

When nobody can honestly describe the work yet. A fixed price on unknown work is a guess with a contract attached, and one side loses: the builder, who then cuts corners, or you, when the builder pads the price to cover the unknown.

• Rescuing an existing codebase. Until someone has read the code, the size of the job is unknown. Pay for a short assessment by the hour or day, then fix the price of the repair.
• Research and prototypes. "Can an AI model do this reliably on our data?" is a question, not a scope. Time-box it.
• Continuous product work after launch. When priorities change weekly, fixing each change is overhead. A monthly retainer (a form of T&M) fits better; mine for fractional CTO work starts at $6,000 a month.
• Very small, frequent tasks. Fixing the price of a two-hour job costs more in paperwork than it saves.

What are the risks of each?

Both models fail in predictable ways. Knowing how is most of the protection.

Hourly billing on an unclear scope is one of the structural causes I go through in why founders waste $50K on agencies.

What are the hybrid options?

Most good contracts are hybrids. The four I'd consider, in order of how often I'd recommend them to a founder:

1. Scoping first, then a fixed price per phase. A short scoping step produces the PRD and design doc; each phase after that has a fixed price. You can stop after any phase. This is closest to how I work.
2. Capped time and materials (not-to-exceed). Hourly, with a ceiling the builder can't pass without written approval. Good when the scope is mostly clear but one part is uncertain.
3. Time-boxed fixed fee. A fixed fee for a fixed number of weeks, with a prioritised backlog. Scope flexes; price and date don't. Useful for prototypes.
4. Retainer. A monthly fee for ongoing work and availability, after launch.

Does a fixed price mean a fixed scope and a fixed date?

A fixed price fixes the cost of a written scope. It doesn't freeze the scope, and it only fixes the date if the contract says so. Project managers talk about the iron triangle: scope, cost and time. You can pin two; the third has to give. A fixed-price contract pins cost and scope, so when something changes, either the date moves or the scope does.

That's why the change process matters more than the price. The healthiest version, in my experience of quoting builds, lets you swap a feature for one of similar size at no cost, and prices anything bigger before work starts. The founder stays in control of what gets built; the builder stays accountable for the number.

A fixed date is a separate promise. If a launch date really matters (an event, a funding deadline, a season), say so before the quote, and expect the builder to protect it by agreeing up front which features drop first if time runs short. That list belongs in the statement of work.

What should you ask a builder before signing either kind of contract?

1. "What exactly does this price include, and what isn't included?" Look for testing, deployment and handover, and an explicit out-of-scope list.
2. "How did you get to this number?" A real estimate can be broken into pieces. A number that can't be explained hasn't been estimated.
3. "What happens when I change something?" You want a written process, not "we'll figure it out".
4. "How will I see progress?" Working software on a schedule, not status reports.
5. "For hourly work, what's the cap, and how will I see hours against it?" Weekly, in writing.
6. "Whose accounts does it run on?" Yours, from day one, on both models.

How do you estimate software development time before agreeing a price?

Bottom-up. Break the scope into pieces small enough to reason about, a few days each, estimate each piece, add them, then give a range that skews upward, because forgotten items are always additions. The industry name is bottom-up estimation over a work breakdown structure, and the honest output is a range, not a number.

You can do a first pass yourself. My free app cost calculator does exactly this with every weight shown, and the method behind it explains each assumption. Then write a PRD, so the builder's estimate starts from the narrow end of the cone, not the wide one.

Which should a founder choose?

For a new MVP: scoping first, then a fixed price. For a rescue: a paid assessment, then a fixed price for the repair. For anything after launch: a retainer or capped T&M, with a demo every week.

Whichever you pick, the contract only works if three things are written down: the scope (and what's out), how a milestone is accepted, and how changes are handled. My plain-English SOW template has all three, and the MVP cost breakdown shows what a fixed MVP quote should contain.

If you have a written scope and want a fixed quote against it, here's how I work.