Fixed Price vs Time and Materials vs Dedicated Team: How to Pay for Software Development

Before a software project starts, you and your supplier have to agree on more than what gets built. You also have to agree on how the work is paid for, and that choice decides who absorbs the cost when the plan turns out to be wrong. In software, some part of the plan usually is.

Three engagement models cover most custom software development work: fixed price, time and materials, and a dedicated team. None of them is the safest or the cheapest in general. Each one fits a different level of certainty about what you need.

This guide explains how each model works, where the risk sits, what to check in the contract and which mistakes cause the most trouble. It quotes no rates, because the right model depends on the shape of your project and not on a number.

How the three engagement models work

Fixed price

You agree a written scope, a total price and a delivery schedule before work begins. Payment is normally split across milestones, such as approved designs, a working beta and final delivery. The supplier is paid for the result, not for the hours it took.

Time and materials

You pay for the time actually worked, at agreed rates for each role, plus any agreed costs such as third-party licenses. The scope can change from one sprint to the next. You receive timesheets and regular invoices, usually monthly.

Dedicated team

You reserve named people, for example two developers, a tester and a part-time project manager, who work only on your product for a recurring fee per person. You set the priorities; the supplier handles employment, equipment and replacements. It is close to time and materials with reserved capacity: you pay for availability whether or not your backlog is full.

Who carries the risk when the scope turns out wrong

Under fixed price, the supplier carries the risk of underestimating. The US Federal Acquisition Regulation, which governs US government purchasing, says a firm-fixed-price contract places maximum risk and full responsibility for all costs on the contractor. Private contracts are not bound by that regulation, but the logic is the same. The buyer does not escape risk, though. Suppliers add contingency to the price to cover unknowns, and you carry the risk that the specification itself was wrong. If you learn halfway through that users need something different, you will still receive what was specified unless you pay to change it.

Under time and materials, the buyer carries the cost risk. The same regulation notes that this model gives the contractor no positive profit incentive for cost control or labor efficiency, which is why it requires oversight by the buyer and a ceiling price that the contractor exceeds at its own risk. Both safeguards are worth copying in a private contract.

With a dedicated team, you carry the cost risk and the utilization risk as well: if you cannot supply clear priorities, you pay for idle time. The supplier's main risk is keeping the team staffed and stable.

What a change request is

A change request is a written proposal to alter the agreed scope, price or timeline after the contract is signed. It describes the change, states its effect on cost and delivery date, and takes effect only when both sides approve it.

In a fixed-price project, a change request is the only legitimate way to change what is being built. In time and materials or a dedicated team, most changes are simply a reordering of the backlog, and a formal request is needed only when a budget cap or a deadline moves. A fixed-price project that generates a steady stream of change requests is telling you the scope was fixed too early.

Which model suits which project

Fixed price suits a small, well-defined project: a marketing website, an integration with a documented API, or a clearly specified feature for an existing system. A useful test is whether you could write the acceptance criteria today. If you can describe how you will know each item is finished, the scope is probably stable enough to price.

Time and materials suits an evolving product. A first release where user feedback will reshape the roadmap, or the replacement of a legacy system whose business rules nobody documented, cannot be specified accurately in advance. Paying for actual effort lets you change direction without renegotiating.

A dedicated team suits a long-running product with continuous work for many months, where it matters that the same people keep their knowledge of your code and your business. It is a poor fit for short or intermittent work. Whichever model you choose, the total still depends on the same underlying factors, covered in our guide to custom software development cost drivers.

Hybrid models worth considering

The most common hybrid is a paid discovery phase followed by a fixed-price build. Discovery is a short piece of time-and-materials or small fixed-fee work that produces requirements, wireframes, a technical approach and an estimate. The UK government's Service Manual describes discovery as understanding the problem before you commit to building, and says around 4 to 8 weeks is typical for a government service; a smaller commercial product may need less. Make sure the contract states that you own the discovery outputs, so you can take them to another supplier if you choose.

Other hybrids include time and materials with a cap, where you pay for actual time up to an agreed ceiling, and fixed price per phase, where each release is scoped and priced separately. Many products also change model over their life: fixed price for the first release, then a dedicated team or a time-and-materials arrangement once the product is live and priorities shift every month.

What to check in the contract for each model

Fixed price

Check that the scope document is attached to the contract and that it lists what is excluded. Milestones should be tied to deliverables you can see working, not to calendar dates. Look for written acceptance criteria, a defined review period, a change request procedure with the rates that apply, and a warranty period for fixing defects after delivery.

Time and materials

Check the rate for each role and the conditions under which rates can change. Ask for a budget cap or an alert threshold, timesheets detailed enough to show what was done, the right to query hours before paying, and a short notice period for pausing or stopping work.

Dedicated team

Check who the named team members are and what say you have when one is replaced. Look at the minimum term, the notice period for reducing or ending the team, cover for holidays and sickness, and handover obligations at the end.

In every model, confirm when ownership of the code and designs passes to you and that the source code lives in a repository you can access. This is general guidance, not legal advice, so have a lawyer in your own jurisdiction review the agreement.

Common mistakes

• Choosing fixed price for budget certainty when the scope is vague. The certainty is false, because the gaps come back as change requests or disputes.
• Running time and materials with no cap, no sprint estimates and nobody reading the timesheets.
• Comparing fixed-price quotes on the total alone. The lowest bid has often assumed the least, so compare assumptions and exclusions line by line.
• Hiring a dedicated team without a product owner on your side who can keep a prioritized backlog ahead of the developers.
• Accepting milestones such as "50 percent complete" in place of working software you can test.

What to do next

Write down what you already know about the project and what you do not. If the unknowns are few, ask for a fixed-price proposal with the assumptions listed. If they are many, ask for a paid discovery or a capped time-and-materials start. Then ask each supplier which model they recommend and why. A supplier who offers the same model for every project, or who cannot explain where the risk sits, has given you useful information.

Conclusion

Fixed price moves estimating risk to the supplier and works when the scope is small and stable. Time and materials keeps flexibility and puts cost risk on the buyer, so it needs a cap and active oversight. A dedicated team gives continuity for a product that will be developed for a long time. Hybrids, especially paid discovery before a fixed-price build, often give a better balance than any single model.

Entrant Technologies builds websites, web applications, mobile apps and custom software. If you would like a view on which model fits your project, you can request a quote and describe what you know so far.