Here's the crude version: with a fixed price, you're scared of the change request; with time and materials, you're scared of the invoice. That's about right. The fixed price vs time and materials question isn't about which model is cheaper. It's about which kind of uncertainty you're carrying, and who's better placed to carry it.
We use both, for different kinds of work. Here's how we think about the choice, and how to make whichever one you pick safer.
Fixed price vs time and materials: the actual difference
Fixed price means you agree a defined scope and a price for it before work starts. If the work takes longer than estimated, the vendor absorbs it. If you want something outside the scope, it's a change request with its own price.
Time and materials (T&M) means you pay for the hours actually worked, at an agreed rate, plus any direct costs. Scope can move freely. If the work takes longer, you pay for it.
So the trade is simple to state. Fixed price moves estimation risk to the vendor and requires you to define scope up front. T&M keeps scope flexible and leaves estimation risk with you. Everything else (cost, speed, trust) follows from that.
When fixed price is the right call
Fixed price works when you can describe what "done" looks like. A first version of an app with a known core flow. A payment integration with a defined set of cases. A migration from one state management approach to another, like the GetX to BLoC move we've done on a commerce app. In each of these, a competent team can list the screens, endpoints and edge cases, and price them.
It's also the better choice when:
- You need to know the budget before committing, for a board, an investor or a grant.
- You don't have a technical person on your side to review hours and question estimates.
- You're working with a vendor for the first time and want to see output before deeper commitment.
The weakness of fixed price is the big-bang version: one huge scope, one price, one delivery date months out. By the time you see the app, you've learned things that make half the scope wrong, and every fix is a change request. That's why we split fixed-price work into milestones. Each is priced before any code is written, each ends in an installable build, and you can stop between any two. You keep the budget certainty of fixed price without betting everything on a spec written before you'd seen anything working.
When time and materials is the right call
T&M is honest about work that can't be estimated well. We'd pick it for:
- Adding engineers to an existing team. If you have a CTO who sets priorities and reviews pull requests, extra developers working inside your process are naturally billed by time. That's how staff augmentation usually works.
- Exploratory and R&D work. "Can an LLM grade these answers well enough?" or "Why does background location die on this Android skin?" are questions, not deliverables. Pricing them fixed means padding heavily or eating a loss.
- Ongoing maintenance. OS updates, library upgrades, small fixes and monitoring arrive unpredictably. A monthly block of hours fits better than a scoped project.
- Debugging an inherited codebase. Until someone has read the code, nobody knows how deep the problems go.
The weakness of T&M is that nothing stops it except you. Without a cap and someone checking the hours, it drifts. Teams aren't usually dishonest about this. It's just that open-ended work expands to fill the budget.
Making either model safer
If you go fixed price
- Insist on a written scope: screens, roles, integrations, and what's explicitly out.
- Break it into milestones small enough to stop after the first without much lost.
- Define acceptance per milestone: which flows must work, tested how, within what window.
- Agree how change requests are written, priced and approved before work starts on them.
- Make sure IP for each milestone transfers when that milestone is paid, not at the end. Our post on milestone payment schedules has more.
If you go time and materials
- Set a not-to-exceed cap per month or per phase, with written approval needed to go over it.
- Get weekly timesheets linked to tasks or pull requests, not just a total.
- Agree a short notice period so you can stop quickly.
- Name the people billing hours, and their rates. Watch for unannounced juniors being added.
- Review output weekly: what shipped, not just what was worked on.
Either way
Own the repository, the app store accounts and the cloud projects from day one. Get a written update every week. Talk to the people who write the code, not only to the ones who sell it. These matter more than the pricing model. A badly run fixed-price project and a badly run T&M project fail the same way: you find out too late, and you don't control the code.
Our default
For a new product, we start with fixed-price milestones, because founders usually need budget certainty and because the first milestone teaches both sides how the project behaves in practice. For engineers joining an existing team, or for open-ended maintenance, time-based billing with a cap is fairer to everyone. Mixing the two over a project's life is normal: build the first version fixed, then move to a capped monthly arrangement once it's live.
orithLabs is a two-founder studio in Delhi NCR, and the people who scope your work are the ones who write it. If you're not sure which model fits your project, bring it to a free 15 or 30 minute call. We'll tell you what we'd pick and why, whether that's a scoped build or engineers working inside your team.