Fixed Price vs Time and Materials for App Development

What you are actually choosing

The real difference between app contracts appears after the first surprise. An API behaves differently from its documentation, users stumble over the approved flow, or a business rule changes halfway through delivery. One proposal turns that discovery into a change request; another asks the client which planned work should move down the backlog.

Before that moment, both proposals can look equally convincing. One offers a single price and the other invoices actual work, but the headline number says little about how the relationship behaves under pressure. In our view, that behaviour is what the buyer is really choosing.

The model should therefore follow the level of uncertainty, not an instinctive preference for certainty or flexibility. A fixed price cannot make an unclear product clear. Time and Materials preserves room to learn, but without budget and delivery controls it can drift just as easily.

This guide is commercial planning information, not legal advice. Contract language and the legal effect of each model depend on the jurisdiction and the agreement itself.

Fixed price, often shortened to FP, means that the supplier agrees to deliver a defined result for an agreed sum. Work outside that definition usually requires a change request. Time and Materials, or T&M, means that the buyer pays for the agreed roles and time actually used, usually against a prioritised backlog. A hybrid contract combines bounded and flexible parts.

The choice changes four things at once: how uncertainty is priced, how changes enter the project, how often the buyer must make decisions and which evidence is used to control progress. It does not make the app itself simpler. Payments, account recovery, admin operations and legacy integrations still have to be designed and tested; the contract merely decides how the parties respond when the estimate meets reality.

When fixed price is a sensible choice

A fixed price works best when two independent teams could read the scope and reach roughly the same understanding of the result. That requires more than a feature list. User roles, business rules, supported devices, integrations, content responsibility, migration, analytics, release work and acceptance criteria need enough detail to test what "done" means.

Good fixed-price candidates include a small internal utility with three known workflows, a design implementation against approved screens and a stable API, or a narrowly defined migration whose source data has already been inspected. The supplier can estimate these jobs because the important questions have already been answered.

Before signing, check that the proposal includes:

• a scope baseline and an explicit list of exclusions;
• assumptions about APIs, data quality, designs, content and client response times;
• milestone deliverables and acceptance criteria a non-technical owner can verify;
• a procedure for defects, scope swaps and genuine additions;
• ownership and access to source code, design, infrastructure and store accounts;
• a release definition that includes testing, analytics and handover rather than stopping at "development complete".

The mobile app development contract checklist covers these controls in more detail. A lawyer should review the final agreement where the commercial or regulatory risk warrants it.

Why a fixed price can still grow

The phrase "fixed price" applies to the defined scope, not to every interpretation the buyer had in mind. If the proposal says "user profile" but does not define verification, account deletion, failed states, support access and profile editing, both sides can honestly imagine different work.

Unknowns are handled in one of three ways. The supplier includes contingency in the quote, excludes the uncertain area, or prices it later through change requests. None is inherently improper. The problem appears when the buyer cannot see which route was used.

Change requests also alter negotiating leverage. Once the project is underway, changing supplier is expensive, so a small missing rule can cost more than it would have during scoping. Ask for the change mechanism before the first change: who describes the impact, whether work stops, whether scope can be swapped instead of added and how the release date moves.

The current Match.dev comparison is useful on this point: a fixed proposal often contains a risk allowance because the supplier commits before every unknown is visible. That is a reason to improve the scope, not a reason to demand that all uncertainty disappear into the supplier's margin.

How to run T&M without writing a blank cheque

T&M is appropriate when learning is part of the work. A first MVP may change after usability tests. A legacy integration may reveal undocumented data. An AI feature may need evaluation before its behaviour is reliable. In these situations, pretending that every task is known can create a rigid contract around the wrong solution.

Flexible billing only works when the buyer can connect time to decisions and usable output. Ask for a simple control system:

1. Role rates and team shape. Know which roles may bill, their rates and the expected weekly capacity.
2. A visible prioritised backlog. Every substantial item should have a purpose, acceptance notes and an owner.
3. A short budget forecast. Review money spent, likely spend to the next milestone and the uncertainty behind the forecast every week or fortnight.
4. Working demonstrations. A timesheet proves activity; a demo proves that activity produced something testable.
5. A budget cap. The team must ask before crossing the agreed ceiling. Reaching it should trigger a scope decision, not a surprise invoice.
6. A pause and stop right. The buyer should receive usable code, access and documentation if priorities change.

The cap is not a promise that all original wishes fit inside the number. It is a decision boundary. As the cap approaches, the owner chooses among reducing scope, adding budget, changing the solution or stopping with the strongest releasable version.

This is also why buying purely on the lowest hourly rate is misleading. The useful measure is the cost of reaching an accepted product milestone. A senior team that removes unnecessary work may have a higher rate and a lower total cost than a cheaper team that implements every request literally.

The hybrid model is often more honest

Many app projects contain both stable and uncertain work. A hybrid contract lets each part use the model it can support.

One practical structure is a fixed-price discovery phase that produces the user journeys, prototype, technical risks, backlog, release boundary and estimate assumptions. Development then runs under capped T&M, with fortnightly demos and budget reviews. A final store-release and handover gate can be fixed if its inputs and acceptance criteria are known.

Another option fixes a narrow first milestone, such as login plus the main transaction, while integrations and post-launch improvements remain flexible. This is different from hiding open-ended work behind a fixed headline. The proposal should show which items belong to each commercial bucket.

Launch Day Advisors' buyer-side guide treats the model as risk allocation rather than a billing preference. That is the useful lens: put each risk with the party able to observe and control it, then create evidence that neither side has to rely on optimism.

Four common app scenarios

A small operational tool with approved rules. Staff sign in, scan an item, select one of five statuses and export a report. Devices and data are known. Fixed price can work because the workflow and acceptance test are stable.

A consumer MVP searching for product-market fit. The main problem is credible, but onboarding, retention mechanics and monetisation still need testing. Capped T&M or a hybrid model is usually more useful than paying for a large frozen specification.

An app connected to an old ERP. Screens may be clear while the integration is not. Start with a bounded technical investigation or paid proof. Fixing the whole project price before inspecting the API, data and permissions encourages exclusions or a large risk allowance.

An existing product with monthly experiments. There is no final scope because learning never stops. A monthly capacity agreement can work, provided the team reports the budget, shows outcomes and allows capacity to change. The mobile app development process helps separate delivery stages from an endless stream of tasks.

A six-question test before choosing

You do not need technical expertise to answer these questions:

1. Can we describe one release that would still make sense if no new feature were added?
2. Are the designs, content, data and external systems available for inspection now?
3. Can a business owner accept or reject each important result using written criteria?
4. Do we expect user feedback or market learning to change priorities during development?
5. Can someone on our side review a demo and make scope decisions every one or two weeks?
6. Which uncertainty is cheaper to carry: a supplier's contingency or our controlled ability to change direction?

Mostly stable answers favour fixed price. Several open answers favour T&M with a cap. A stable core surrounded by open integrations or product decisions points to a hybrid.

If the team cannot answer the first three questions, the immediate purchase may be a prototype, technical proof or scoping phase rather than full development. The prototype, proof, pilot and MVP comparison explains what each asset should prove.

Red flags in either kind of proposal

A fixed-price proposal is weak when it promises certainty but lacks acceptance criteria, named dependencies or a change process. Watch for a low headline followed by broad exclusions such as "backend supplied by client" when no usable backend exists.

A T&M proposal is weak when it lists rates but no expected team, first milestone, reporting rhythm or budget ceiling. Access only at the end is another warning: the buyer should not need to wait for a dispute to discover where the code and accounts live.

Under either model, ask how quality work is represented. Product decisions, UX, QA, analytics, release preparation, project management and handover are real work. A proposal that mentions only developer hours may be incomplete, not efficient. Use the app estimate preparation guide to assemble the inputs that make commercial comparisons meaningful.

How Appfyl prepares the estimate

When Appfyl estimates a mobile product, we separate the known release scope from assumptions that still need evidence. The estimate maps user roles, core journeys, data, integrations, admin operations, analytics, release work and ownership. Open questions remain visible so they can become a bounded investigation, a flexible backlog item or an explicit exclusion rather than a late surprise.

Use the Appfyl app estimate brief to describe the product in practical language. It will not choose a contract for you, but it exposes the functions and dependencies that determine whether a responsible fixed price is possible. You can also review Appfyl's mobile app development work and released cases.

Want to see how Appfyl turns scope into shipped products? View Appfyl cases.

Questions people ask