“Finance needs one number before they’ll approve this.” “Nobody knows what’s really inside the old system.” If you’re the operations leader or IT manager signing the software contract, you may hear both in the same week. This guide looks at both software development pricing models from the buyer’s side: where each model puts the risk, how hybrids work, which structure suits which project and the clauses worth having either way.
The short answer: fixed price vs time and materials at a glance
Fixed price trades flexibility for a known number. Time and materials trades a known number for flexibility. The question that decides between them isn’t which one is cheaper. It’s how much of your project is still unknown on the day you sign.
How fixed price works, and where the risk goes
In a fixed-price software contract, you and the vendor agree on a defined scope and a single price before work begins. If the build takes longer than estimated, the vendor absorbs the overrun. U.S. federal procurement rules describe a firm-fixed-price contract as one that places on the contractor “maximum risk and full responsibility for all costs and resulting profit or loss” (FAR 16.202-1).
That risk doesn’t vanish, though. It gets priced, and some of it comes back to you in three places:
- Contingency in the price. A careful vendor adds a buffer for unknowns. If the unknowns never show up, you’ve still paid for the buffer.
- Change orders. Anything the specification doesn’t say is extra. When the spec is thin, a fixed price turns into a series of negotiations.
- Pressure at the end. When hours run short, the incentive is to meet the letter of the spec: less testing, thinner documentation, and the edge case nobody wrote down left for later.
When fixed price genuinely protects you
Fixed price works when the scope is clear enough that two different vendors would build roughly the same thing from the same document. The federal rules make the same point: fixed price suits work with “reasonably definite functional or detailed specifications” where fair prices can be set at the outset (FAR 16.202-2). In software, good candidates include:
- A discovery or assessment phase with a defined deliverable, such as a written findings report and estimate
- A bounded change to a system the vendor already knows: one new report, one more approval step, one added field
- A marketing website with a fixed page list and approved designs
Test your spec before asking for a fixed price
Give the specification to a colleague who wasn’t in the meetings and ask them to list every screen, user role, data field and connected system. Each question they come back with is a future change order. Our software RFP template walks through the sections vendors need so they all price the same thing.
How time and materials works, and how to keep it honest
Under time and materials, you pay for the hours actually worked at agreed rates, plus direct costs such as third-party licenses or hosting. Scope can change as you learn, which is the point. On a stalled project, or an integration with a system nobody documented, no one can honestly price the work until someone has looked inside.
The trade-off is that the estimate risk moves to you. Federal rules are blunt about it: a time-and-materials contract “provides no positive profit incentive to the contractor for cost control or labor efficiency,” so the buyer has to oversee the work, and a federal T&M contract must include “a ceiling price that the contractor exceeds at its own risk” (FAR 16.601). You don’t need government paperwork, but both controls carry over: oversight and a ceiling.
Five habits that keep T&M under control
- A cap or not-to-exceed amount per phase or month, with written notice at a threshold you choose (say, 75% of the cap) so you decide before the money is gone.
- Hours reported against named work items, not one monthly total. You should be able to see which feature, fix or meeting used the time.
- Demos of working software every week or two, on a test copy you can click through yourself. A status report describes progress; working software shows it.
- A prioritized list of work that you control. You decide what gets built next, and the team tells you roughly what each item will take before it starts.
- A named decision-maker on your side. T&M hours keep running while engineers wait for answers about your process.
Example (hypothetical): where the estimate risk lands
A vendor estimates a new internal tool at 300 hours. On a fixed-price quote, they might add 25% for unknowns and price it as 375 hours. On T&M, if the work lands at 290 hours, you pay for 290; if an awkward integration pushes it to 410, you pay for 410 unless a cap stops the clock. Which costs less depends on how good the estimate was, and that depends on how well the scope was understood. Illustration only, not a quote or a typical figure.
Hybrids: capped T&M, phased fixed price and retainers
You don’t have to pick one model for the whole project. Hybrids match the pricing to how much is known at each stage.
Capped time and materials (a not-to-exceed contract)
You pay for actual hours, up to a ceiling. As spending approaches the cap, work pauses for a decision: trim scope, move items to a later phase or approve more budget in writing. Finance gets a number to approve, and you keep the ability to change priorities.
Ask whether the cap is hard (the vendor finishes the agreed scope at its own cost if it runs over) or soft (work stops and you decide what happens next). Both are legitimate. The contract should say which.
Phased fixed price
Split the work into short phases and fix the price of the next phase only. A common shape is a fixed-price assessment that produces a written scope, a risk list and an estimate, followed by build phases priced one at a time as each becomes well understood. Write the contract so you can stop after any phase and keep everything delivered so far.
Retainers for ongoing work
Once software is live, the work becomes a steady stream of small items: security updates, bug fixes, a new form field, a report a manager asked for. A monthly retainer (a set block of hours or a defined scope of support each month) fits that stream better than repeated fixed-price quotes. Check what happens to unused hours, how urgent issues outside the block are handled and billed, and how either side ends it. The web application maintenance checklist lists the recurring tasks to cover.
Example (hypothetical): one project, three structures
An operations team wants to replace a spreadsheet-based purchase-approval process. Phase 1: a fixed-price assessment that maps the workflow and the systems it touches, ending in a written scope and estimate. Phase 2: a capped T&M build of the request, approval and reporting screens, with a demo every two weeks. Phase 3: a monthly maintenance retainer once the tool is in daily use. Not client data.
Not sure which structure fits your project?
Your first call is with an engineer. Bring the systems involved and what you already know, and we’ll talk through which parts can be scoped now and which need discovery before anyone can price them honestly.
Which pricing model fits which kind of software project
Choosing time and materials vs fixed price for a software project depends less on its size than on what’s still unknown when you sign. Here’s how common project types line up.
A software project rescue starts with an honest look at what exists; pricing the finish line before that is guesswork for both sides. Suspect your project belongs in that row? The software project health check flags the warning signs in plain language.
When you modernize an old web application, the first pages show how the old code behaves, which is what makes the later pages possible to price. For what drives the size of the number, see how much custom software costs.
Contract clauses that protect you under either model
The pricing model decides who carries the estimate risk; these clauses decide whether you can recover when something goes wrong. Use them as a checklist for your attorney, who should review the final wording. This isn’t legal advice.
Change orders
Every change to scope, price or a cap goes through one written process: who can request a change, how it gets estimated and which named person on your side approves it before work starts. No verbal approvals. Under T&M, the same rule applies to anything that would move the ceiling.
Acceptance criteria
For each deliverable, write testable statements of “done”, such as “a supervisor can approve a request from a phone, and the requester receives an email.” Agree how long you have to test, what counts as a defect and how fixes are handled. Watch for clauses that treat silence as acceptance after a short window.
Caps and payment terms
Tie payments to accepted deliverables rather than calendar dates, and put a cap on each phase or month. If the contract has a cap, it should say exactly what happens when the cap is reached.
IP assignment
Who owns the code is a legal question, separate from who can log in. Under the Copyright Act, commissioned work counts as “made for hire” only if it falls into one of nine listed categories and both parties sign a written agreement saying so (U.S. Copyright Office, Circular 30). Custom software doesn’t always fit those categories neatly, which is why your attorney may recommend pairing a work-for-hire clause with a written assignment of copyright to your company.
Check when ownership transfers (as the work is created, on delivery or only after final payment), ask for a list of third-party components and their licenses, and get clear terms for any pre-existing tools the vendor brings.
Accounts in your company’s name
The domain, hosting or cloud account, code repository, database, app store developer accounts and third-party API keys should be registered to your company, with the vendor added as a user. If the vendor owns the accounts, owning the code on paper won’t get you into them. The software handover checklist lists every account to check.
Exit and handover terms
Agree how either side can end the contract and with how much notice, what you pay for work done to date, and what you receive on the way out: source code, database exports, documentation, credentials and a handover period. These terms cost nothing to write while everyone is getting along. If you’re already mid-project and thinking of leaving, read how to switch software developers mid-project.
Questions to ask a software vendor before you sign
Ask these of every vendor on your shortlist, in writing, so the answers can be compared side by side.
- What exactly is included in the price or estimate, and what’s explicitly excluded?
- Which assumptions is the estimate built on, and what happens if one turns out to be wrong?
- How will we see progress: demos, a test environment, hours by work item?
- Who will write the code, and can we talk to them directly?
- How are change requests estimated and approved, and who can approve them on our side?
- What happens when spending approaches the cap?
- How is “done” defined for each deliverable, and how long do we have to test it?
- Who owns the code, and when does ownership transfer?
- Whose name will the hosting, repository, domain and app store accounts be in?
- After launch, who handles security updates, bug fixes and small changes, and how is that billed?
- If we part ways, what do we receive, and how does the handover work?
Push hardest on vague answers to questions 2, 8 and 9. Comparing several firms? Put these questions into your brief with the RFP template, and see how to choose a software development company for the rest of the evaluation.
Still deciding what kind of team to bring in: a freelancer, an in-house hire or a software development partner? Settle that first; it shapes which models are on the table. More buyer-side reading is in our guides.