Fixed Price App Development: What a Change Order Costs

What a change order is, and what it is not

A change order is a written request to add, remove or replace something in the agreed scope. Before any work starts, it should state the new work, its price and what it does to the date. You sign it or you refuse it. Many requests are not change orders at all. If an agency bills any of the three below as a change, the scope document was too vague. Check for that before you sign. Our MVP development agency page shows what a scoped v1 includes at a fixed price, so you can compare it with any quote you already have.

• A bug. If a feature in the scope doesn't work as agreed, fixing it is part of the job.
• A clarification. If the scope says "users can reset their password" and the screen is missing, building it is still the original work.
• A visual tweak inside the agreed design. A colour, a label or a line of copy is not new scope.

Fixed price vs hourly app development: who carries the risk of change

The real difference between the two models is who pays when the work turns out bigger than expected. Here is how fixed price and hourly (time and materials) compare:

• Price of the agreed scope. Fixed price: set before the build. Hourly: known at the end.
• Who carries the risk of underestimating. Fixed price: the agency. Hourly: you.
• Mid-build changes. Fixed price: written change order, approved first. Hourly: added to the running hours.
• Unclear requirements. Fixed price: must be settled before the quote. Hourly: paid for while they get settled.
• What you need to start. Fixed price: a defined v1. Hourly: a budget ceiling and time to manage it.
• Best for. Fixed price: a clear v1 with a launch date. Hourly: ongoing work after launch.

Verdict by situation

For the contract clauses behind each model, read Fixed Price vs Time and Materials for an MVP: 13 Clauses.

• You know your v1 and need a launch date (investor demo, market window, a competitor launching): go fixed price. A change costs you a signature, not a surprise.
• You can't describe the first version yet: run a short scoping step first, then take a fixed price on a defined v1.
• Your app is live and you add features every week: hourly or monthly support makes more sense than a string of change orders. See our continuous support page.

What a change order actually costs

The price on a change order is only the part you see. When you read a change order, check that all three costs below are written down. A price with no date is half an answer. A request made mid-build has three costs:

• 1. The work itself. New screens, new logic, new data. Agencies price this one of two ways: hours multiplied by a rate, or a fixed price for the change. Ask which method yours uses before you sign the main contract.
• 2. The ripple. One new feature touches more than its own screen. Adding a second user role, for example, changes the sign up flow, what each screen shows, the database rules and the test plan.
• 3. The date. If the change sits on the path to launch, everything after it moves. For a founder with an investor meeting or a launch event, this is often the cost that hurts most.

The same request early, mid-build and near launch

Timing changes the cost more than the feature does. Our MVP is delivered in about 20 days, and the MVP development agency page lists the steps: Free Strategy Call, Design Sprint, Build Sprint, then Launch & Handoff. The lesson: say every idea out loud on the first call, even the half-formed ones. Hearing "that's v2" before the quote costs you nothing. Here is what happens to one request, "add a group booking option", at each stage:

• Free Strategy Call, before the quote. What it touches: nothing yet. Likely outcome: goes into the scope and the fixed quote. No change order.
• Early, during the Design Sprint. What it touches: screens and flows on paper. Likely outcome: cheapest moment. Often a swap with another feature of similar size.
• Mid-build, during the Build Sprint. What it touches: code, database, tests already written. Likely outcome: real change order, with new work, ripple and possibly a new date.
• Late, near Launch & Handoff. What it touches: release build, store submission. Likely outcome: best parked for version 2 so the launch date holds.

Fixed price app development: sort every request before it becomes a bill

When a new idea comes up mid-build, put it in one of these five boxes before you ask for anything. Written down, many ideas turn out to be swaps or v2 items. You make that call on paper, before anyone writes code. Halfway through scoping and not sure which box a feature belongs in? Book a call and we'll sort your list with you. The five boxes:

• Defect. Example: checkout button fails on Android. Who pays: the agency. Effect on date: none.
• Clarification. Example: missing "forgot password" screen already in scope. Who pays: the agency. Effect on date: none.
• Swap. Example: replace in-app chat with email notifications. Who pays: usually neutral, agree in writing. Effect on date: usually none.
• New feature. Example: add referral codes. Who pays: you, by change order. Effect on date: possible.
• New platform or provider. Example: add a second payment provider or an external CRM. Who pays: you, by change order. Effect on date: likely.

How to scope a fixed price app contract so changes stay rare

Change orders come from decisions left open. To see what triggers a custom quote before the build starts, read Fixed Price MVP: What's Included vs a Custom Quote. Settle these before the quote:

• Write flows, not feature names. "Booking" means nothing. "A client picks a slot, pays by card, gets a confirmation email" can be priced.
• Decide on login methods. Email, Apple, Google or phone number. Each one is its own piece of work.
• Decide who pays and how. One-off payment, subscription or in-app purchase. Each has its own setup and store rules.
• Count your user types. One role or several. Every extra role multiplies screens and permissions.
• List every outside service. Maps, SMS, analytics, CRM. Each new provider is a new integration.
• Keep a v2 list from day one. Every idea goes on it. Nothing gets lost and the build stays on track.
• Read the change clause. It should say that changes are quoted in writing and nothing is billed without your approval.

How BuildMVPFast handles a request outside the scope

Our MVP is Fixed at $3,460, delivered in about 20 days. Design is included, progress is shown every week, 100% of the code sits on your GitHub, and you get 2 weeks of fixes after launch. The fixed quote is given before we start. For anything outside the standard package, our MVP development page says it plainly: "tell us what you need and we'll send a fixed quote or phased roadmap." The best time to raise those extras is the Free Strategy Call, so they are settled before the build begins. So if you have a defined v1 and a date to hit, the fixed-price MVP package lists everything that comes Fixed at $3,460, line by line. Check your feature list against it and you'll know exactly what is covered and what would need its own quote. Want to know what your idea would cost, and which parts belong in v2? Book a call.

What is a change order in app development?

It is a written document for a request outside the agreed scope. It states the new work, its price and its effect on the launch date. Nothing should be built or billed until you approve it.

Is fixed price app development more expensive than hourly?

Not by default. With a fixed price the agency carries the risk of underestimating, so the quote rests on a precise scope. With hourly billing you pay for every hour, including the hours spent on unclear requirements. The clearer your scope, the better a fixed price works for you.

Can I swap a feature without paying for a change order?

Often, yes, if the new feature is about the same size and you ask early, ideally during design. Agree the swap in writing so both sides know what came out and what went in.

What happens if a fixed price project needs more work than planned?

That depends on where the extra work comes from. In principle, a fixed price contract means the agency carries the cost of underestimating the agreed scope. Check that your contract says so in writing. If the extra work comes from a new request, it usually goes through a change order you approve before work starts.