Fixed price or time and materials.

The wording of US federal procurement rules is a useful reference because it is precise. A firm-fixed-price contract provides for a price that is "not subject to any adjustment" on the basis of the contractor's costs while performing the work (FAR 16.202-1). A time-and-materials contract "may be used only when it is not possible" to estimate the extent or duration of the work accurately at the start (FAR 16.601(c)).

Those two sentences carry the whole idea. Fixed price needs a scope that is known well enough to price. Time and materials exists for work where the scope is not yet known. A software project can sit between the two, which is why the choice depends on how much you know before you sign.

In software contracts, a fixed price is also called a fixed fee, and the contract works the same way. This guide compares the two contract types for custom software development, shows how each handles change and budget, and covers the hybrids. For what drives a quote up or down, read the cost guide.

Safe means different things to each side. A fixed price protects the buyer's budget, but only while the scope holds still. Once the scope moves, the contract becomes a series of change requests, and the vendor has a reason to protect margin by keeping the original wording narrow.

Time and materials protects the buyer's ability to learn and adjust. It gives up certainty about the final cost, so it needs more attention from the buyer: someone has to review the hours and the progress they bought.

The Agile Manifesto (2001) values "responding to change over following a plan". A fixed price rests on following a plan. Time and materials rests on responding to change. A software project can use some of each, and the section on combining the two shows how.

Read the table as tendencies, not rules. Contracts add caps, milestones and approval steps that move a fixed price toward flexibility and time and materials toward predictability.

1. Describe the change: what should be different, and why it matters now.
2. Estimate it: the vendor states the extra work and any effect on work already planned.
3. Agree the effect: the revised price, the moved milestones and anything that drops out to make room.
4. Approve it in writing: both sides sign off before work on the change begins.
5. Record it: the scope document is updated, so the next change starts from the current picture.

Changes are normal and not a sign of failure. The risk is a contract with no clear way to handle them. Ask any vendor on a fixed price how a change is requested, who prices it, how long an estimate takes and who approves it on your side. A clear answer before signing prevents disputes later. The software project brief template lists what to write down before you ask for a quote, so a later change is easy to tell apart from the agreed scope.

• A spending cap: an agreed ceiling that the team may not pass without your written approval.
• Milestones: points where you review working software, then decide whether to continue, change direction or stop.
• Regular check-ins: short reviews where the team shows what was built and what comes next.
• Hours against progress: reports that tie the hours worked to the features finished, so cost and output are read together.
• A ranked backlog: the most valuable work first, so that if the budget runs out the important parts exist.

The cap and the reviews work together. A cap without reviews only tells you the budget is gone after the fact. Reviews without a cap give you information but no limit. Name one person on your side who reads the reports and can approve or stop work.

• Fixed-price first phase, then time and materials: the first phase settles scope and design at a known price, and later work follows as the team learns.
• Fixed price per milestone: each milestone is priced when it is planned, so scope is agreed one piece at a time instead of all at once.
• Time and materials with a cap: work follows the hours, but a ceiling and approval steps limit the total.

The pattern to choose follows the uncertainty. Price the part you can define and keep the rest flexible. Whatever the mix, put the rules for change and for approval in writing, and agree which parts are priced up front and which are billed as they go. The vendor guide covers how to compare these pricing models when you assess companies.

After the discovery call, Foxefy researches your processes, data and systems, then proposes the work as milestones and deliverables. You review the proposal before work starts, so both sides know what is being built and in what order.

Foxefy also provides dedicated teams, an option when the work continues after launch. Product engineering explains when that fits. Foxefy does not promise a price before the scope is known. To see how a project runs from first call to support, read how Foxefy works. To start, book a discovery call and bring your questions about fixed price and time and materials.