Fixed price vs time and materials: which fits an app or MVP?

Fixed price vs time and materials comes down to scope. For an app or MVP, a fixed price works once the scope is written as two lists: what's in version 1 and what's out. Time and materials works when nobody can yet say what done looks like. Idea-stage estimates "can be inaccurate by a factor of 4x on the high side or 4x on the low side" (Steve McConnell, Construx, 2010). A fixed price quoted from a two-line email is a guess. Below: who carries which risk, how we run a fixed scope, and what triggers a change request.

What is the difference between fixed price and time and materials in app development?

A fixed price contract sets one price for a defined scope before work starts, and the price doesn't move with the hours the team actually spends. Time and materials (T&M) means you pay for the hours worked at agreed rates, plus outside costs such as hosting or licences at what they cost.

Useful public definitions are in the US Federal Acquisition Regulation (FAR), the rulebook for US government buying. It's written for federal contracts rather than apps, but the logic carries over (both pages checked 1 November 2026):

• A firm-fixed-price contract has "a price that is not subject to any adjustment on the basis of the contractor's cost experience in performing the contract", and it "places upon the contractor maximum risk and full responsibility for all costs and resulting profit or loss" (FAR 16.202-1).
• A time-and-materials contract "may be used only when it is not possible at the time of placing the contract to estimate accurately the extent or duration of the work or to anticipate costs with any reasonable degree of confidence" (FAR 16.601). The same section warns that it "provides no positive profit incentive to the contractor for cost control or labor efficiency", which is why the buyer has to watch the work closely.

Two variants sit in between. Capped T&M is time and materials with a ceiling; FAR 16.601 calls for "a ceiling price that the contractor exceeds at its own risk". A monthly retainer pays for a set amount of a team's time each month, so it's T&M priced by the month, usually with the same people throughout.

Who carries the risk under each model?

Under a fixed price, the team carries the cost risk and you carry the scope risk. Under time and materials, you carry the cost risk as well.

A fixed price doesn't remove risk. It moves it to the team, and a team that carries an overrun prices that in. It also gives the team a reason to deliver the written list and nothing beyond it. That's fine when the list is right and a problem when the list is vague. Time and materials pulls the other way, which is the FAR warning above.

Neither model fixes the last row. Trying a working build every week, and getting it in front of real users early, is the protection we rely on.

Why can't a team fix a price from a two-line idea?

Because at that stage nobody knows the size of the work, the team included. McConnell's white paper calls this the Cone of Uncertainty: how wide an honest estimate is at each point in a project. He presents it as a best case: "The Cone represents the error in estimates created by skilled estimators. It's easily possible to do worse."

Here's what that does to an idea a team thinks is about 600 hours of work. The 600 is made up to show the arithmetic; the multipliers are from the white paper.

A team that fixes a price at the first row has two choices: pad the number heavily, or hope. Neither is good for you.

The cone doesn't narrow by itself. "The Cone narrows only as you make decisions that eliminate variability", McConnell writes, and the first decision he names is defining the product vision, "including committing to what you will not do". That's why the out-of-scope list matters as much as the feature list, and why we give a price after a written plan and never in reply to a first email. Our project brief template is built to get you from the first row to the third faster.

How we run a fixed scope

This is how a project build runs in our MVP development work, and our other fixed-scope builds follow the same steps.

1. Scope call. We go through your brief: the problem, the users, the one job version 1 must do, and any hard date. Questions come before numbers.
2. Written plan. Before any code: what's in and what's out as two lists, the effort against each feature, milestones with dates, the price, what you need to supply and by which week (copy, prices, legal pages, store accounts), and a written assumption for every unknown.
3. Acceptance checks. Each line in scope is written as something a user can do, plus how we'll both know it works. "Staff mark an order as ready and the customer gets a notification" can be checked. "Order management" can't.
4. Weekly builds. Every week you get a version on your phone through TestFlight or a Google Play testing track, or a preview link for web work, with a call or written notes.
5. Sorting feedback. Everything you send after a build goes into one of three groups: a defect, a clarification or a change. Defects and clarifications are part of the price. Changes get written up as change requests.
6. Milestone sign-off. At each milestone you try the build against that milestone's lines. Lines that pass are done. Lines that fail are defects, and we fix them.
7. Release and handover. Store submission, then the code, accounts, keys and documentation.

The acceptance checks come from how we fix bugs in our own apps: the expected behaviour gets written down first, and the fix is tested against it. A plan works the same way. If "done" isn't written down, every milestone turns into a negotiation.

What triggers a change request?

A change request is triggered by anything that makes the product do more than the written plan says, or something different from it, and by any written assumption that turns out to be wrong. A detail the plan left open is a clarification. A bug in something the plan lists is a defect. Neither is a change.

Store rules need their own line in any plan, because they move every year. Since 31 August 2026, new apps and app updates on Google Play must "target Android 16 (API level 36) or higher" (Play Console Help), and since 28 April 2026, apps uploaded to Apple "must be built with Xcode 26 or later" using the iOS 26 SDK (Apple Developer), both checked 1 November 2026. A plan written in July for a September release should already include the Android 16 work, and if it doesn't, you'd expect the team to absorb it. A requirement announced after signing is different, and the plan should say who carries it.

In apps we've shipped, raising the Android target is a job we plan for every year. Smaller surprises turn up too. A newer release of a common permissions plugin needed one of our projects to compile against Android API 37, one level above the API we were targeting, and the build failed until we changed it. The obvious one-line fix didn't work either, because of how the new SDK is packaged. It was a small job, but nobody had planned for it, and on a fixed scope someone has to carry that time.

AI features need their own acceptance rule. The plumbing is ordinary engineering with a known shape. In the AI apps we've shipped, the model sits behind our own backend and every answer is parsed and checked in code. An answer cut off halfway counts as a failure, and failed calls retry, then fall back to a second provider. We'd fix a price for that. Answer quality depends on your real inputs, so in a fixed scope we'd agree a set of real examples up front, with what a good answer looks like for each, and treat them as the acceptance test. A failure on an agreed example is a defect. A higher bar is a change.

What does a change request look like?

Example (hypothetical): a café pickup app. The plan says customers order for collection as soon as the food is ready, and lists table booking and delivery as out. In week 4, after trying a build, the owner asks to let customers choose a collection time up to 3 days ahead.

Here is the change request as we'd write it. The hours are made up for the example.

Change request 03, raised in week 4

Asked for:  Customers choose a collection slot up to 3 days
            ahead. Staff see orders grouped by slot. At most
            10 orders per 15-minute slot.
Plan says:  Line 4: "order for collection as soon as it's ready".
Effort:     Slot picker screen               10 h
            Slot limits in the backend       14 h
            Staff view grouped by slot        8 h
            Reminder before the slot          6 h
            Testing on Android and iOS        8 h
            Total                            46 h
Options:    A. Add it. The price rises by 46 hours at the
               plan's rate. Milestone 3 and the release
               move by 1 week.
            B. Swap it. Build today-only slots with no limit
               (20 h) and move "order history" (20 h in the
               plan) to the later list. Price and dates stay.
            C. Later. Put it on the version 2 list.
Decision:   [option, your name, the date]

Whatever you choose, the plan gets a new version number, so there's one current document and a record of why it changed. Option B is easy to overlook: a fixed scope can change shape without changing price, as long as something of the same size comes out.

What should a statement of work contain?

A statement of work (SOW) is the document that says what will be delivered, by when, for how much, and how both sides will know it's done. Ours is the written plan. US federal rules ask agencies to "describe the work in terms of the required results" instead of how it's done or how many hours it takes (FAR 37.602), and that instinct fits an app too: list outcomes a user can check.

Payment terms, ownership and warranties are contract matters. This is general information, not legal advice, so have a lawyer in your country read the agreement. Our 15 questions to ask a software development company turns most of these rows into questions you can send before you sign.

When is time and materials the better choice?

When the work can't be written as a finished list, and someone on your side has time to steer it every week.

• A live product. After launch, priorities come from usage data and support messages, and they change weekly. Pricing each small change as its own fixed piece adds paperwork to every task. That's what our monthly product retainer is for: the same engineers each month, working through a backlog you rank.
• An unknown codebase. "Fix whatever is wrong with this app" can't be priced until someone has read the code. Get it read first, then fix a price for a specific outcome.
• Research-heavy work, such as an integration with an undocumented system, where the first weeks decide what's possible.
• You have a product owner: someone on your side who ranks the work, accepts or rejects it and reads the hours report. Without that person, T&M drifts.

It's the wrong choice when your budget is a hard number and there's no cap, or when nobody on your side can judge whether the hours were well spent.

The Agile Manifesto is often quoted in favour of T&M: "Customer collaboration over contract negotiation" and "Responding to change over following a plan" (agilemanifesto.org). The line after the four values is quoted less: "while there is value in the items on the right, we value the items on the left more." A written plan with a change process is how a fixed scope responds to change and still has a plan.

What we would do

For a first version, we'd fix the scope and the price, then move to monthly work once the product is live. That's how our own engagements are set up: a project build with a fixed written plan, then a product retainer if you want the same engineers to keep going. The conditions:

• Fixed price, if you can fill in the first 3 sections of a brief (the problem, the users and the one job) and accept a written out-of-scope list. A first version that does one job for one kind of user usually can.
• Neither yet, if you can't. A clickable prototype, or a few conversations with people who have the problem, will narrow the cone faster than any contract.
• A split, if the core of the product is research, such as an AI feature whose quality you can't define yet. Fix the price for everything around it, and agree real test examples for the uncertain part before the build starts.
• Monthly, after launch, once the backlog is set by what users do.

Whichever model you choose, ask each team to show you how it writes a change request before you sign. That page tells you more about the next 3 months than the hourly rate does.

Your next step

Use this rule: if you can write down what's out of version 1, ask for a fixed price against a written plan. If you can't, no team can honestly give you one, and a T&M quote won't tell you the total either.

Once you have quotes, compare them line by line before you compare totals; our app cost guide shows how. When your brief is ready, send it through our contact page or to hello@zoftaa.com, and we'll start with questions.