"Can you just give us a fixed price?" It is one of the most reasonable questions a business can ask a software company, and one of the hardest to answer well. The choice of fixed price vs time and materials, or a dedicated team billed by the month, decides who carries the risk when the project changes, and software projects nearly always change. Pick the wrong model and you either overpay for certainty you did not need or lose control of a budget you thought was safe.
Here is how each model works, what it really costs you, and how to choose.
Three ways to buy software work
Fixed price means you buy an outcome. The vendor agrees to deliver a defined scope for a set fee. If it takes longer than they thought, that is their problem. If you want something that is not in the scope, that is a change request, priced separately.
Time and materials (T&M) means you buy effort. You pay for the hours actually worked at an agreed rate, usually with a weekly or monthly report of what those hours went on. The scope can move, and the budget moves with it.
A dedicated team means you buy capacity. You pay a monthly fee for named people, for example two developers and a part-time tester, who work only on your product and take direction from you or your product owner. It is closer to having staff than to buying a project.
Fixed price vs time and materials: who carries the risk
Every estimate has uncertainty in it. The only question is who pays for it.
With a fixed price, the vendor carries the risk, so a sensible vendor adds a buffer to cover it. You pay that buffer whether or not the risks happen. The vendor also has a reason to read the scope narrowly, because every extra hour comes out of their margin. That is not bad faith; it is how the model is built, and it is why fixed-price projects tend to produce arguments about whether something was "in scope".
With time and materials, you carry the risk. If a feature turns out simpler than expected, you save money. If it turns out harder, you pay more. In exchange you get flexibility: you can change priorities every week without renegotiating a contract. The risk you need to manage is drift, where the project keeps growing because nobody is saying no.
A dedicated team moves even more control, and more responsibility, to you. The monthly cost is predictable, but what you get for it depends on how well the work is directed. A team with no clear priorities will still be busy. It just will not be busy on the right things.
The same project, priced three ways
A hypothetical example makes this concrete. A distributor wants a web dashboard where its sales staff check stock across three warehouses, create quotes, and email them to customers as PDFs. After a scoping call, the vendor estimates 400 hours, give or take 30%, using the features-times-hours method from our guide to budgeting an app. Assume a rate of $35 an hour, purely for illustration.
- Fixed price. The vendor has to cover the chance that the job takes 520 hours, so they quote something like 480–520 hours' worth: $16,800–$18,200. If the job takes 380 hours, the vendor keeps the difference. If the distributor later wants a portal where customers see their own quotes, that is a new quote.
- Time and materials. The distributor pays for the hours used. The likely cost is around $14,000 for 400 hours, with a realistic spread of $9,800–$18,200. The customer portal can be added halfway through without a contract change, but someone on the distributor's side has to watch the weekly spend.
- Dedicated team. Two developers and a half-time tester for three months, at roughly 160 hours a month per developer and 80 for the tester, is 1,200 hours of capacity: about $42,000. That is far more than this project needs. A dedicated team only makes sense here if the dashboard is the first of a long line of internal tools.
None of these numbers is wrong. They answer different questions. Fixed price answers "what is the most I will pay?" Time and materials answers "what is the least I can pay for what I turn out to need?" A dedicated team answers "how do I get steady development capacity without hiring?"
When each model fits
The fixed price vs time and materials question usually answers itself once you are honest about two things: how well you already know the scope, and how much time you can give the project each week.
Choose fixed price when
- The scope is small and can be written down completely: a marketing site, a clear integration, a well-understood feature.
- You have a hard budget ceiling set by someone else, and certainty matters more than the last dollar.
- You can describe what "done" looks like with acceptance criteria both sides can check.
Avoid it when you are still learning what the product should be. Every new discovery becomes a change request, and the paperwork slows everything down.
Choose time and materials when
- You are building a new product and expect to adjust based on what users do.
- Someone on your side can make decisions every week and review the work.
- You want to be able to pause or change direction without renegotiating.
Avoid it if nobody on your side has time to direct the work. T&M without an engaged client is how budgets drift.
Choose a dedicated team when
- Software is ongoing work for you, with a backlog that stretches months ahead.
- You have a product owner or technical lead who can set the team's priorities.
- You want people who build up knowledge of your product and stay with it, without the cost and commitment of hiring.
Avoid it for a one-off project with a clear end, because you will pay for capacity you do not use. If you do go this way, here is how you can hire dedicated developers through us. If that team will be offshore, our practical guide to hiring developers in India is worth reading first.
Hybrids that often work better
In practice, many healthy projects mix models:
- Fixed-price discovery, then a T&M build. A short, fixed-fee phase produces requirements, designs and an estimate. The build then runs on time and materials against that estimate, so both sides know what "on track" looks like.
- Fixed price per milestone. Break the project into milestones of a few weeks each and fix the price of the next one only. Uncertainty shrinks as you go, and so do the buffers.
- T&M with a cap. Hours are billed as used, up to an agreed ceiling for a defined scope. If the cap is getting close, the vendor has to say so early, not after the money is spent.
- Start with one paid milestone. Before committing to a whole project, pay for one clearly defined piece of work and judge the result. We offer this at CodeSalen because judging delivered work tells you more than judging a proposal.
The thinking behind these is not new. The Manifesto for Agile Software Development values "customer collaboration over contract negotiation" while still granting that contracts have value. A contract works better as a frame for collaboration than as a weapon for disputes.
What to check in the contract, whichever model you pick
- Change process. How are changes requested, estimated and approved, and who can approve them on your side?
- Acceptance. What counts as done, how long you have to test, and what happens to bugs found after sign-off.
- Reporting. For T&M and dedicated teams, weekly timesheets or task-level reports, not a single invoice at month end.
- Ownership. You should own the source code and have access to the repository from the first week, not only at handover.
- Exit. The notice period for a dedicated team, and what handover you get if you part ways: code, documentation, credentials.
- People. Who will actually do the work, and whether you can talk to them directly rather than only through an account manager.
A quick decision rule
If you can write the whole scope on two pages and it will not change, ask for a fixed price. If you are building something new and can give it a few hours of attention every week, use time and materials, ideally with a cap or milestones. If software is a permanent part of how your business runs, look at a dedicated team. And if you are still unsure, start with a small, fixed-price piece of work and decide after you have seen it delivered.
When you are ready to compare, you can see how we price projects and teams, or describe your project to us and we will tell you which model we think fits, and why.
