Two quotes for the same project
It's common for a business owner to get two quotes for the same piece of work and find they look nothing alike. One is a single number with a list of features underneath. The other is an hourly or daily rate and an estimate of how many days it'll take, with a note that the final figure depends on what comes up. Comparing them feels impossible, and the instinct is to go with the one that gives you a firm number.
That instinct is understandable, but it's worth knowing what each kind of quote actually promises before you sign. The two models put the risk in different places, and that matters more than the headline figure.
What fixed price actually means
A fixed price quote says: for this defined scope, we'll deliver for this amount. If it takes longer than expected, that's the developer's problem, not yours.
The key words there are "defined scope". A fixed price only holds while the scope stays still. The quote will list what's included, sometimes in detail and sometimes loosely, and anything outside that list becomes a change.
Because the developer carries the risk of the work taking longer, a sensible fixed price includes contingency. Software is hard to estimate. Integrations behave differently from their documentation, content arrives late, and edge cases appear once real users touch the thing. A developer who quotes a fixed price without allowing for that is either very experienced with that exact kind of project or about to lose money, and a developer losing money on your project tends to start cutting corners or arguing about what was in scope.
So with a fixed price you're paying for certainty. That's often worth it. But you're paying for the contingency whether it gets used or not.
What time and materials actually means
Time and materials means you pay for the hours or days actually worked, at an agreed rate. The developer usually gives an estimate up front, but the estimate isn't a promise.
Here the risk sits with you. If the work turns out simpler than expected, you pay less. If it turns out harder, or you change your mind about something halfway through, you pay more. You're not paying for contingency you don't use, and you have the freedom to change direction without renegotiating a contract.
The trade-off is that you need to stay involved. Time and materials works well when there's regular reporting, a clear view of what's been spent against what's been delivered, and someone on your side who's paying attention. Without that, it can drift.
Change requests are where fixed price gets tested
Almost every project changes once it's underway. You see the first version and realise the booking flow needs another step. A staff member points out the report needs one more column. A supplier changes their system. None of that is anyone's fault. It's what happens when an idea turns into a working product.
On a fixed price project, each of those becomes a change request: the developer assesses it, quotes it, and you approve or decline it. Done well, this is fair and transparent. Done badly, it turns into a running argument about what the original scope meant, with every conversation starting from "that wasn't included". We've taken over projects where the relationship broke down for exactly this reason, long before the software did.
On a time and materials project, the same change is simply more work. It still costs money, and a good developer will tell you how much before doing it, but there's no contract to reopen.
The middle ground
Most projects don't need to sit at either extreme, and in our experience the better options are in between.
Capped time and materials is one. You pay for the time actually worked, up to an agreed ceiling for a defined piece of work. If it comes in under, you pay less. If it would go over, the developer has to stop and talk to you before spending more. You get some of the certainty of a fixed price without paying for all the contingency.
Phased delivery is another. Rather than quoting the whole project at once, the work is split into stages, and each stage is priced once the previous one is done and the next is better understood. The early estimates for later stages are rough, and everyone knows it.
And then there's starting with discovery. A short, paid piece of work at the front of the project to work out what's actually being built: the users, the workflows, the integrations, the unknowns. At the end you have a much clearer scope, and whatever pricing model you pick for the build is far more reliable. We've written about what a discovery phase should actually deliver if you want to know what to expect from one.
Which model suits which project
A rough guide, based on the projects we see.
Fixed price suits work that's well understood and unlikely to change much. A brochure website with a set number of templates, a store on an established platform with standard features, or a small, clearly defined addition to an existing system. If you can write down exactly what you want on a page or two, fixed price is usually reasonable. Our guide to briefing a developer helps with that.
Time and materials suits work with genuine unknowns. Custom software that replaces an internal process, anything involving several third-party integrations, a new product where you expect to learn from early users, or rescue work on an existing codebase where nobody knows what's inside until they look.
Capped or phased approaches suit the large middle: projects that are mostly clear but have a few uncertain parts.
Ongoing work after launch is different again. Support, small improvements and maintenance are usually better handled through a retainer or a block of hours than through a string of small fixed quotes. We covered that in retainer vs project work.
Red flags in a quote
Whichever model a quote uses, a few things should make you ask more questions.
A fixed price with a vague scope is the main one. If the quote says "e-commerce website" and not much else, there'll be a disagreement later about what that includes. Ask for the detail before you sign, not after.
A time and materials estimate with no breakdown is another. You should be able to see roughly where the hours are expected to go, so you can tell later whether the project is on track.
Watch for quotes that don't mention testing, deployment, content entry, training or handover. Those are real work, and if they're not in the quote, they'll either be skipped or turn up as extras.
Be wary of a quote that's much lower than the others without an obvious reason. Sometimes a developer has done something similar before and can reuse work. More often something has been left out, or the contingency is missing and the shortfall will come back as change requests.
And check who owns the work at the end. The code, the designs, the hosting accounts and the domain should be yours. If the quote is silent on that, ask.
Getting a quote you can trust
The best quotes we see, from anyone, share a few things: they say what's included and what isn't, they're honest about what's uncertain, and they explain how changes will be handled before any arise. The pricing model matters less than whether both sides understand what they've agreed to.
When we quote, we'll usually tell you which model we think fits your project and why, and if the scope isn't clear enough to price fairly, we'll say so and suggest a discovery step first. If you've got a project in mind, or a quote you'd like a second opinion on, get in touch.
