Fixed Price vs Time and Materials: Choosing How to Pay for Custom Software in Australia

Every software quote you receive hides a second question underneath the first. The first question is “how much?” The second is “who pays if we’re wrong?” Most business owners only ask the first, and then wonder why a project quoted at one number ends up costing another, or why a supplier who promised a fixed price has gone quiet and started saying “that’s out of scope.”

The contract model is where that second question gets answered. Fixed price, time and materials, milestone-based fixed price and capped time and materials are four different ways of dividing risk between you and whoever is building your software. None of them is the honest one and the others the dodgy ones. Each is the right tool for some projects and the wrong tool for others, and picking the wrong one is how reasonable people end up in expensive arguments.

We build custom software, and we have views on this, so we’ll declare our bias early. We lean towards fixed quotes for well-understood work and we say so on our own pricing page. But we’ve also seen where fixed price goes wrong, and this guide covers that honestly, along with how to choose, how to protect yourself under either model, and what to ask before you sign.

What each model actually means

The terms get used loosely, and two suppliers can mean quite different things by “fixed price.” Before comparing, it helps to pin down what each model is in practice.

Fixed price

The supplier agrees to deliver a defined scope for a defined price. If the work takes longer than they estimated, that’s their problem. If it takes less, they keep the difference. The important word is “defined.” A fixed price is only as firm as the document describing what’s being built. A vague scope with a firm price isn’t certainty, it’s a dispute waiting for a trigger.

Fixed price usually comes with a change request process. Anything not in the agreed scope gets estimated and priced separately before it’s built. That’s not a trick; it’s the mechanism that makes a fixed price possible. But it’s also where most of the friction lives, and we’ll come back to it.

Time and materials

You pay for the effort actually spent, usually at an hourly or daily rate, plus any materials or third-party costs. The supplier gives an estimate, but it’s an estimate, not a promise. If the work is bigger than expected, you pay more. If it’s smaller, you pay less.

Time and materials (T&M) puts the budget risk with you and the efficiency risk with them. That sounds like a bad deal for the client, and sometimes it is. But it also means nobody is incentivised to argue about scope, because there’s nothing to defend. If you change your mind in week six, the team just starts building the new thing.

Milestone-based fixed price

This splits a larger project into stages, each with its own fixed price and its own definition of done. You approve and pay for one stage before the next is committed. It’s a fixed-price contract broken into smaller bets.

The advantage is that scope for stage three doesn’t have to be nailed down on day one. You learn from stages one and two, then price stage three with real information. The cost is that you don’t get a single total figure upfront, only a total that firms up as you go.

Capped time and materials

Work is billed by time, but there’s a ceiling. The supplier can’t invoice beyond the cap without your agreement. If the work finishes under the cap, you pay for hours used. If it looks like it will exceed the cap, there’s a conversation before the money is spent rather than after.

This one is underused. It gives you the flexibility of T&M with a budget limit that actually binds the supplier, and it’s often the most honest structure for work where the shape is mostly known but not entirely.

Where the risk actually sits

Strip away the contract language and these models are a dial. At one end the supplier carries the risk of overrun. At the other, you do. Everything in between shares it in some proportion.

That sounds like fixed price is simply safer for the client, and plenty of buyers reason exactly that way. It isn’t that simple, because risk doesn’t disappear when a supplier takes it on. It gets priced in, or it gets managed in ways that affect you.

What a fixed price quietly includes

A supplier quoting a fixed price on work with real unknowns has to protect themselves. They do that in one or more of these ways: add a contingency buffer to the number, write the scope narrowly so that anything uncertain falls outside it, or plan to recover cost through change requests. Each of those is rational. None of them is free for you.

When you receive three fixed quotes for the same brief and one is far lower than the others, it’s worth asking which of those three mechanisms is doing the work. A low fixed price from a supplier with a narrow scope and a generous change request rate is not cheaper than a higher quote with the scope written properly.

What T&M quietly includes

Time-based billing carries a different hazard. If the supplier earns more when the work takes longer, the incentive is mildly misaligned with yours. Most good suppliers manage that through transparency: weekly reporting, a visible backlog, regular demos of working software, and an honest conversation when something is taking longer than planned. But the structure itself doesn’t force that behaviour. You’re relying on the supplier’s habits.

That’s the reason capped T&M exists. The cap puts a hard edge on the incentive without freezing the scope.

Neither model removes the real risk

The biggest cost risk in any software project isn’t who holds the contract risk. It’s building the wrong thing. A perfectly delivered fixed-price build of the wrong feature set costs you the full price and then costs you again to fix. A T&M project that uncovers the wrong direction in week three and pivots may cost less in total, even with the pivot, because you stopped early.

So the right question isn’t only “who carries the overrun risk?” It’s “which structure helps us find out soonest if we’re heading the wrong way?”

When fixed price works well

Fixed price earns its place when the work is well understood. That means the requirements can be written down specifically, the technology is familiar to the team, and the number of unknowns is small. A few examples of work that tends to suit it:

• A defined integration between two systems with documented APIs, where both sides have been inspected before quoting
• A marketing or ecommerce site on an established platform with a clear page list and feature set
• A migration with a known source, a known destination and a data audit already completed
• A discrete internal tool with one core workflow, a clear user list and agreed screens
• A small, bounded enhancement to existing software the supplier already knows well

What these have in common is that someone has already done the thinking. The scope document isn’t a guess; it describes something both parties understand.

What makes a fixed price trustworthy

A fixed price you can rely on tends to come with the following, and the absence of any of them is worth a question:

• A written scope that lists what’s included and, just as importantly, what isn’t
• Acceptance criteria for each deliverable, so “done” isn’t a matter of opinion
• A stated number of revision rounds on design or content, rather than “reasonable revisions”
• A defined process and a rate card for changes, agreed before work begins
• Named assumptions, such as “client supplies content by week two” or “third-party API access is granted before build”

Assumptions deserve special attention. They’re where a fixed price quietly becomes conditional. If the quote assumes your data is clean and it isn’t, or assumes a vendor will provide sandbox access and they take six weeks, the price may legitimately move. That’s fair, as long as it was written down at the start rather than discovered during the dispute.

What fixed price costs you

Even good fixed-price work has a cost in flexibility. Once the scope is signed, you’re in a rhythm of change requests, and every change has a small ceremony around it: someone describes it, someone estimates it, someone approves it. For a project where you expect to learn as you go, that ceremony adds up. Teams start to avoid raising changes because of the paperwork, which means you ship something that matches the document and not necessarily the need.

There’s also the discovery gap. Fixed-price work needs a scope, and producing a good scope is real work. If a supplier gives you a firm number after a thirty-minute call on something complex, either the work is simpler than you think or the number has a very large buffer in it.

When time and materials works well

T&M is the right structure when you’re building something you can’t fully specify yet. Not because you’ve been lazy, but because the information doesn’t exist until you start. Some typical situations:

• A new product where user feedback will shape the next sprint
• An evolving internal platform where priorities shift monthly
• Work on a legacy codebase where the real problems only appear once you start changing things
• Research-heavy work such as a proof of concept using AI or a technology the team hasn’t used before
• Ongoing development after launch, where you’re buying capacity rather than a deliverable

What makes T&M safe

Time-based billing is safe when you can see what’s happening. That means a few practical protections, none of which are exotic:

• A short written estimate with a range, not just a single figure, and the assumptions behind it
• Weekly or fortnightly reporting that shows hours spent against what was delivered
• Regular demos of working software, not slide decks about progress
• A budget alert threshold, for example a conversation at 75 per cent of the estimate
• The right to stop at the end of any sprint without penalty

Working software on a regular cadence is the most reliable control. If every second Friday you can click through something real, you’ll know within a month whether the project is on track. Reports about work are easy to polish. Software that runs is not.

What T&M costs you

The cost is predictability. If your board or your cash flow needs a firm number, open-ended T&M is uncomfortable, and you can feel that discomfort throughout the project. You also take on a management load. Someone on your side has to prioritise the backlog, answer questions quickly and make decisions, because idle time is billable time. Teams that treat T&M as “set and forget” tend to be disappointed.

The hybrid most sound projects end up with

In practice, the cleanest engagements rarely use a single model end to end. Uncertainty isn’t constant across a project. It’s highest at the start, when nobody has confirmed the real requirements, and it falls as decisions get made and software starts to exist. A contract structure that follows that curve is usually better than one that ignores it.

Discovery first, and priced on its own

The most useful thing you can buy before committing to a large build is a small, fixed-price discovery phase. It covers the real workflow, who uses the system, what it connects to and any security or compliance requirements. The output is a scope you can price properly, a list of the risky parts and, often, a clearer view of what you don’t need to build at all.

Discovery changes the conversation. Instead of comparing three vague proposals, you hold a document that any competent supplier could quote against. If you choose to take that document to another team, you can. A supplier who is confident in their value doesn’t need to trap you in a free scoping exercise to keep the work.

Build in stages

For the build itself, you choose between milestone-based fixed price and capped T&M depending on how well the scope is understood. Where the pieces are clear, fixed milestones give you cost certainty stage by stage. Where parts are exploratory, capped T&M gives flexibility with a ceiling.

The point of staging is optionality. After each stage you can continue, change direction or stop, and you’ve paid only for what exists. That’s a very different risk profile from committing the whole budget on day one against a specification that’s a few weeks old.

Launch and the unglamorous parts

Testing, data migration and go-live are the stage most often underestimated, and they’re a good candidate for a fixed price once the build is done, because by then the system exists and can be inspected. Pricing launch work in advance, before anyone has seen how messy the data really is, is how projects arrive at go-live weekend with a surprise.

Support priced separately

After launch, ongoing development and support are a different kind of purchase. You’re buying capacity and responsiveness, not a deliverable. A monthly arrangement sized to your actual needs usually works, with the freedom to scale up or down. Be wary of support contracts that lock in long terms before you’ve seen what the software needs in the real world.

Fixed price vs time and materials: how to choose for your project

You can usually work out the right structure with a handful of questions. Answer them honestly, because the temptation is to describe your project as more certain than it is.

How much of the scope can you write down today?

If you can list the screens, the user roles, the integrations and the rules that govern them, and a developer could read that list and build from it, the project is well-defined and fixed price is reasonable. If your list has phrases like “something like” and “we’ll know it when we see it,” you’re in discovery territory. That’s not a problem; it just means the first thing you buy is clarity.

What happens if you learn something halfway?

Imagine that three months in you discover users don’t behave the way you assumed. How easily can the project absorb that? In a rigid fixed-price contract, the change goes through a request, an estimate and an approval, and may cost real money. In a staged or T&M arrangement, you adjust the next sprint. If you expect to learn a lot, buy flexibility.

How firm does your budget actually have to be?

Some budgets are genuinely hard limits, for example a grant, a board-approved amount or a fixed capital allocation. Others are soft in practice, with room for a sensible conversation. If the budget is hard, favour fixed price or capped T&M. If it’s soft, T&M may deliver more value because you can spend where it matters.

Who will manage the project on your side?

T&M works best with a decision-maker who has time to engage. If nobody on your side can attend demos, answer questions within a day or prioritise the backlog, fixed price protects you from your own bandwidth. The supplier owns the schedule, and you give approvals at defined gates.

How well does the supplier know your systems?

A team that’s already worked with your CRM or accounting package can price an integration with confidence. A team meeting your legacy ERP for the first time is guessing, however professionally they phrase it. Familiarity shrinks the unknowns, and fixed price becomes more honest as the unknowns shrink.

What this means for common project types

Rather than leave this abstract, here’s how we’d generally think about a few typical projects. These are rules of thumb, not rules, and every project has its own wrinkles.

An MVP or first version of a product

An MVP exists to test whether the idea works, which means the scope will change as soon as real users touch it. We’d normally start with a fixed-price discovery and design phase, then build in short fixed-scope sprints, each tied to something testable. The aim is to stop spending as soon as you’ve learned what you needed to. If you’re at this stage, our MVP development service is built around exactly that approach of building lean and validating before you commit more.

A defined integration or migration

If both systems have documented interfaces and the data has been audited, fixed price is a good fit. The scope is bounded and the unknowns are mostly technical rather than strategic. Where the audit hasn’t happened yet, price the audit separately and quote the migration afterwards.

A customer portal or internal tool replacing spreadsheets

These sit in the middle. The core workflow is usually known, but the edge cases hide in how people actually use the spreadsheet today. A fixed-price discovery followed by milestone-based builds tends to work well, with the most contentious workflow built first.

Work on an existing codebase

Modifying software you didn’t build is the clearest case for T&M or capped T&M, at least initially. Neither party knows what’s in there until they’ve been in there for a while. A fixed-price code audit first reduces the unknowns, and afterwards you can decide whether to fix price the changes.

Ongoing development and feature work

Once software is live, you’re typically buying a stream of changes with shifting priorities. T&M or a monthly allocation is the natural fit. Fixed-pricing every small request is more administrative effort than it’s worth.

Reading a quote: red flags and green flags

Whatever model is proposed, the document tells you a lot about the supplier. A few things we’d look at carefully if we were on the buying side.

Red flags

• A fixed price offered quickly, on a complex brief, without any discovery or technical questions
• A scope described in a paragraph rather than itemised deliverables
• No mention of what’s excluded, or of assumptions
• A change request rate much higher than the project’s blended rate, which can signal a plan to recover margin later
• Payment schedules weighted heavily to the start, before anything exists to inspect
• T&M with no estimate, no reporting commitment and no way to stop cleanly
• Unclear ownership of the code and data when the project ends

Green flags

• Questions about your workflow and your users before any number appears
• A written scope with acceptance criteria and named assumptions
• Payments tied to delivered, demonstrable work
• A candid view of which parts of the project are uncertain and how they propose to handle that
• Willingness to separate discovery from build, so you can leave after discovery if it’s not a fit
• Clear terms on ownership, which we cover in our guide to who owns your custom software

The Australian contract context

Two practical points for Australian buyers. First, check whether prices are quoted including or excluding GST, particularly when comparing quotes side by side, because the difference changes the comparison by a tenth. Second, the unfair contract terms provisions of the Australian Consumer Law were strengthened for standard form contracts with small businesses, and civil penalties now apply. That doesn’t mean a lopsided software contract is automatically unenforceable, and it isn’t a substitute for reading the contract carefully, but it’s worth being aware of if you’re signing a supplier’s standard terms. For anything significant, have a lawyer read the agreement. We’re not lawyers, and nothing here is legal advice.

Payment structure matters as much as pricing model

Two suppliers can both offer a “fixed price” and give you very different levels of protection through the payment schedule. When money moves relative to delivered work is a form of risk allocation too.

Tie payments to things you can see

A common pattern is a deposit to start, then payments at defined milestones where something demonstrable has been delivered, with the final portion held until acceptance. The final payment is the one that keeps a supplier engaged during the dull parts: the bug fixing, the documentation, the handover. A schedule that front-loads almost everything weakens your position at the point you most need it.

Equally, suppliers are entitled to a reasonable deposit. They’re committing capacity and often paying contractors or licences before anything is invoiced. A deposit of a sensible size isn’t a red flag. A very large payment before any visible work is.

Keep T&M invoices readable

For time-based work, invoice at a regular interval, such as monthly or per sprint, with a breakdown that links hours to outcomes. If you can’t tell what you paid for from the invoice, you can’t manage the budget. This is as much a service quality issue as a billing one.

Common mistakes

These are the errors we see most often, from both buyers and suppliers.

• Treating a fixed price as a guarantee of the outcome. It guarantees a price for a described scope. If the scope doesn’t describe what you need, a fixed price just locks in the wrong thing at a known cost.
• Choosing the lowest fixed quote without comparing scope. Differences between quotes are usually differences in what’s included, not in efficiency. Line the documents up item by item.
• Using T&M without a cap or reporting. Open-ended time billing with no visibility is the model’s worst-case form, and avoidable.
• Skipping discovery to save money. It feels economical and often costs more later, because the first sprint becomes an expensive discovery exercise with a bigger team.
• Writing the scope after signing. If the contract says “scope to be agreed,” you have a T&M arrangement with a fixed-price label.
• Ignoring the change process until you need it. Agree how changes are estimated, approved and paid for before the first one arises, not during an awkward conversation about the first one.
• Under-resourcing your own side. Late feedback, slow approvals and missing content are the most common reasons good projects blow out, under any model. Suppliers often build these dependencies into the assumptions.
• Forgetting post-launch costs. Hosting, monitoring, licences, security patches and small fixes continue after go-live. Budget for them from the start.
• Not asking about ownership and handover. The contract model doesn’t change who owns the code, but the contract should state it plainly.

Frequently Asked Questions

Is fixed price always more expensive than time and materials?

Not always, but it often includes a risk premium. The supplier has to absorb the possibility of overruns, so well-run suppliers add some buffer for uncertainty. On well-understood work that buffer is small and the certainty is worth it. On exploratory work, the buffer can be large, and you may pay more for a fixed price than you would for the hours actually needed.

Can I switch models partway through a project?

Yes, and it’s often sensible. A common pattern is fixed-price discovery followed by capped T&M or milestone-based build once the scope firms up. Switching models mid-build is harder, because it usually involves renegotiating scope and reopening the commercial terms. It’s much easier to plan the structure upfront.

What’s a reasonable cap on a capped T&M engagement?

There isn’t a universal figure. The cap is normally set a sensible distance above the supplier’s estimate, based on how uncertain the work is. A tight cap means less flexibility and more change conversations. A loose one gives little protection. What matters more than the number is that the cap is binding, with a clear process for any increase that requires your written agreement.

Who owns the code under a fixed-price contract versus T&M?

The pricing model doesn’t decide ownership; the contract terms do. Under either model you should confirm in writing that the code, database and associated assets transfer to you, and what happens to any third-party or pre-existing components the supplier uses. Make sure this is stated before work begins rather than assumed.

Is paying a deposit normal for software projects?

Yes. A deposit is standard and reasonable, because the supplier is reserving capacity. What matters is its size relative to the project and what the rest of the payment schedule looks like. Payments linked to delivered milestones, with a final amount held until acceptance, protect both parties better than a schedule that pays out most of the fee early.

Should I ask for a fixed price on an AI or automation project?

It depends on how much is known. A defined automation between two documented systems can be fixed-priced after a short assessment. AI work with real unknowns, such as how well a model handles your documents, is better scoped with a fixed-price proof of concept, then priced once there’s evidence of what works. Be cautious of any supplier who fixes a large AI build price without testing the core idea first.

Where to Start

If you’re about to commission software, the single most useful step is to decide how much of your project is known and how much isn’t. Write down the parts you can specify, and be honest about the parts you can’t. That list tells you where fixed price fits, where flexibility belongs and where a small discovery phase would save you the most money.

For well-defined work we quote a single fixed price before any work begins, and for larger builds we phase the work so the cost isn’t one large number on day one. Our web app development pricing page explains what moves the price. If you want a sense of typical market costs before you talk to anyone, our guide to what a custom web app costs in Australia is a good companion to this one. And if you’re considering the full range of what we build, see our web application development service.

Worth saying plainly: because we run lean as a specialist agency rather than carrying a large account-management layer, our fixed quotes typically come in below Australian market averages for comparable scope. If you’ve already got a written quote from another agency for comparable scope, send it through and we’ll do our best to beat it.

If you’re weighing up how to structure a project and want a second opinion, we’re happy to have that conversation. There’s no obligation, and if the answer is that you don’t need custom software yet, we’ll say so.