On a fixed-price software contract the developer carries the risk of the work taking longer than estimated, and charges a premium for carrying it; on a time-and-materials contract the client pays for the hours actually worked and carries that risk instead. Fixed price suits a well-defined project with a hard budget and a client who can't supervise the work closely. Time and materials suits ongoing products and genuinely uncertain work, where a technical client can watch the hours. Shark Labs quotes builds at a fixed price after a short paid discovery, and runs post-launch work as monthly retainers with stated hours.
Most articles on this question are written by agencies explaining why their own billing model is the sensible one. The useful way to think about it is narrower: every software estimate is wrong by some amount, and the contract decides who pays for the difference.
We quote fixed prices, so take this with that in mind. It includes the cases where we'd tell you not to.
The two models, stated plainly
Fixed-price contract
A software contract in which the developer agrees to deliver a written scope for an agreed total, regardless of how many hours it takes. If the work runs over, the developer absorbs the cost. If the client changes the scope, the price changes with it.
Time-and-materials contract
A software contract in which the client pays an agreed rate for the hours actually worked, plus any direct costs, usually invoiced weekly or monthly. The estimate is a forecast, not a promise: if the work takes longer, the client pays for the extra time.
| Fixed price | Time and materials | |
|---|---|---|
| Who pays for an overrun | The developer | You |
| Who pays for a change of mind | You, as a priced change | You, as more hours |
| Budget certainty | High, for the written scope | Low, unless capped |
| What you have to provide | A clear scope, up front | Ongoing attention and someone who can read progress |
| Cost of changing direction mid-build | A negotiation | A conversation |
| The developer's incentive | Finish the scope efficiently | Keep working on what you ask for |
| Typical failure | Arguments about what "done" means | A budget that quietly doubles |
A fixed price is an estimate plus a premium
Nobody prices risk for free. A developer quoting a fixed price takes their estimate and adds a margin for the chance they're wrong. You pay that margin whether or not the risk turns up, which is exactly how insurance works. Here is the arithmetic with round, illustrative numbers — not our rates, and not any particular studio's:
| What actually happens | Hours worked | Time and materials | Fixed price |
|---|---|---|---|
| Estimate was right | 300 | $15,000 | $18,000 |
| Ran 20% over | 360 | $18,000 | $18,000 |
| Ran 40% over | 420 | $21,000 | $18,000 |
| Ran 80% over | 540 | $27,000 | $18,000 |
The crossover sits wherever the overrun equals the premium — here, 20%. Below it, time and materials was cheaper. Above it, the fixed price was. So the real question isn't which model is cheaper, it's how likely a large overrun is on this particular project, and how badly you'd be hurt if one happened.
When fixed price is the right call
- The scope can be written down. A marketing site, an MVP with a hard version-one boundary, a defined feature in an existing product. If you can list what "done" looks like, it can be priced.
- The budget is a ceiling, not a target. Board-approved spend, a grant, a fixed slice of a raise. An overrun isn't an inconvenience, it's a problem.
- Nobody on your side can judge engineering hours. Most founders and small businesses are in this position, and there's no shame in it. Fixed price means you judge the result, not the timesheet.
- It's your first project with this developer. A fixed price with milestone payments limits how much you can lose to a bad fit.
When time and materials is the better deal
This is the section a fixed-price studio has a reason to skip, so here it is in full.
- The product is already live and changing every week. Writing a fixed scope for each small change costs more than the change. Ongoing work on a running product is time and materials in some form, whatever the invoice calls it.
- Nobody knows yet whether it's possible. Research, a spike into a messy legacy system, a performance problem with no known cause. A fixed quote on genuinely unknown work is either padded heavily or a gamble one side will lose.
- You have a strong technical lead. If someone on your side can read a pull request and a burn chart, you can get most of the protection a fixed price gives without paying the premium for it.
- The developer is good at estimating. On the model above, a team that reliably lands within 10% of its estimate is cheaper on time and materials. A track record you can check is worth more than a contract clause.
How each model goes wrong
Fixed price
- A vague scope becomes a fight. "User management" means three screens to one side and an audit log with role permissions to the other. Every gap in the written scope turns into a dispute at the end, when you have the least leverage.
- The change-request mill. A quote priced low to win the work, then made up for through changes. The tell is a scope so thin that nothing useful can be built without amending it.
- Corners cut at the end. When a fixed job runs over, the cheapest hours to remove are tests, documentation and the edge cases you won't notice until later.
Time and materials
- No reason to finish. Nobody needs to be dishonest for a project to drift; it's enough that there is always one more thing worth doing and nobody is counting.
- Hours you can't see into. A monthly invoice reading "development, 160 hours" tells you nothing. Without hours against named tasks, you're paying for time you can't evaluate.
- The budget conversation happens too late. By the time someone notices the spend, it's been spent.
The hybrids that beat either one
Pure fixed price and pure time and materials are both less common in practice than these:
- 01Paid discovery, then a fixed price. A short, small engagement where the developer reads the code and data and writes the scope, followed by a fixed quote against that scope. The estimate is far less wrong because it's made after looking, so the premium can be smaller. This is how we work.
- 02Phased fixed price. One fixed price per milestone rather than one for the whole build, with the next phase quoted when the last one lands. You can stop or change direction at each boundary without renegotiating everything.
- 03Capped time and materials, or "not to exceed". Hourly billing with an agreed ceiling the developer can't pass without your written approval. Closer to fixed price than it sounds, as long as the cap is real and the scope is still written down.
- 04A retainer for after launch. A monthly fee for a stated number of hours. It's time and materials with a predictable invoice, which is the right shape for keeping a live product healthy.
How to read a fixed-price quote
The number is the least informative part of it. Check these before you compare totals:
- A written scope you could hand to another developer. Screens, user types, integrations, and what each one does. If you couldn't get a second quote from it, it isn't a scope.
- An explicit list of what's excluded. Content entry, design, app store submission, hosting setup, data migration. Exclusions are where cheap quotes hide.
- Acceptance criteria. How you'll both decide a milestone is done. Without them, "done" is whatever the developer delivered.
- How changes are priced. A day rate or a method for quoting changes, agreed before you need it.
- Payments tied to delivered milestones, not to dates. Neither side should ever be far ahead of the other.
- What happens when the delivered work doesn't match the scope. It should be fixed at the developer's cost; ask how long that commitment runs.
- Who owns the code and accounts. Everything in accounts registered to you from day one — the handover checklist has the full list.
How to keep time and materials honest
- Hours logged against named tasks, visible to you every week, not totalled on an invoice at the end of the month.
- A running comparison of spend against the estimate, so a 30% drift is a conversation in week three rather than a surprise in week ten.
- A cap per phase, even a generous one. It turns an open-ended commitment into a decision you make again at each boundary.
- A working demo every week or two. Progress you can click on is the only progress report that can't be written to sound better than it is.
- The right to stop with short notice, and everything built so far in your repository when you do.
How Shark Labs prices
Builds are fixed-price. Every project starts with a paid discovery of $400–1,800 in which we read the actual code and data and write the scope, the price and the date. Discovery is credited against the build if you go ahead, and the plan is yours to take elsewhere if you don't. After that the price doesn't move unless you change what's being built: an underestimate on our side is our cost, not a change request.
Projects are paid 40% to start, 30% at an agreed midpoint and 30% on delivery, with more milestones on longer builds. Once a product is live, ongoing work runs as a monthly retainer with the hours stated and thirty days' notice — time and materials with a predictable invoice, because that's the right shape for work nobody can scope a year in advance. Every range is on the pricing page.