"Fixed price" sounds like the safest way to buy an app. You know the number before anyone writes code, and the agency carries the risk if it takes longer. That's true, as far as it goes. But a fixed price Flutter MVP is only as fixed as the scope document behind it, and most disputes we hear about come from things neither side wrote down. This post covers what a fixed price should cover, what it usually doesn't, and how milestones keep both sides honest. It won't give you a number. Any number quoted without your scope is a guess.
What a fixed price Flutter MVP should cover
A fixed price is a promise to deliver a defined thing for a defined amount. "Defined" is doing the work in that sentence. Before you sign, the scope should spell out:
- Every screen and flow, ideally against designs or at least wireframes. "User profile" is not a scope. "Profile screen with photo upload, name and phone edit, and logout" is.
- Platforms and versions. iOS and Android from one Flutter codebase, and the minimum OS versions supported. Supporting very old Android versions can add real testing time.
- The backend. Who builds it, on what (Firebase, Node, Laravel, an existing API), and whether the admin panel is included. An MVP with no way for you to manage content or users isn't finished.
- Integrations, named. Which payment gateway, which SMS or email provider, which maps or analytics SDK. Each one has its own setup, test and review work.
- Non-functional basics: offline behaviour (if any), crash reporting, analytics events, accessibility basics like readable font scaling.
- Store submission. Building release versions, preparing listing metadata you provide, and getting through App Store and Google Play review, including responding to rejections caused by the build.
- Acceptance criteria. How you'll decide a milestone is done. "Works on these five devices, these flows pass, no open crash bugs" is checkable. "Client is happy" isn't.
- A bug-fix window after launch for defects in the agreed scope.
- Handover: source code in your repository, your cloud accounts, your developer accounts, and enough documentation for another team to pick it up.
What fixed price usually excludes
None of these are tricks. They're things that can't be priced honestly in advance, or that belong to you. A good quote names them so they don't surprise you later.
- New features after sign-off. Ideas that come up mid-build go into a change request with its own estimate, or into the next phase. This is the most common source of friction, so agree the process up front.
- Third-party fees. Apple and Google developer accounts, cloud hosting, payment gateway charges, SMS, maps and AI API usage. You pay these directly, on accounts you own.
- Content. Copy, images, product data, legal text such as your privacy policy and terms. Developers can tell you what's needed; a lawyer should write the legal parts.
- Problems outside the codebase. A payment gateway's KYC taking weeks, an app rejected for a business-model reason, a third-party API changing.
- Ongoing maintenance. OS updates, package upgrades and monitoring after the warranty window. That's normally a separate retainer or hourly arrangement.
- Designs, unless explicitly included. Some agencies design, some build from your Figma files. Know which you're paying for.
If a quote doesn't mention any of these, ask. Our post on what an app development quote should include has a fuller list of questions.
Milestones: how a fixed price stays fair
One big fixed price paid in two halves puts all the risk in the middle, where neither side can see it. Milestones fix that. Each milestone is its own small fixed-price piece with its own deliverable and acceptance check, and you should be able to stop after any of them with something usable.
A typical breakdown for a Flutter MVP looks something like this. The actual split depends on the product.
- Scope and architecture. Screen list, data model, integration choices, a written plan. Short, and worth paying for separately: you can take this document to anyone.
- Foundations and first flow. Project setup in your repository, CI, auth, the backend skeleton, and the one flow your product exists for, running on real devices.
- Remaining core features. Often split into two or three milestones by feature area.
- Integrations and hardening. Payments, notifications, analytics, error states, offline handling, performance on lower-end phones.
- Release. Store submission, fixes from review, launch, then the bug-fix window.
Two things make this work in practice. First, weekly written updates, so you see progress and problems as they happen rather than at the milestone demo. Second, you own the repository and the accounts from the first day, so stopping between milestones is a real option and not a threat. We cover payment structure in more detail in how to structure an app development milestone payment schedule.
When fixed price is the wrong model
Fixed price suits an MVP with a clear first version. It suits less well when:
- You're still discovering what the product is, and expect to change direction every few weeks. Time-based work with a capped budget per sprint is more honest here.
- The hard part is research (an unproven AI feature, an undocumented hardware SDK). Do a short fixed-price spike to answer the question first, then price the build.
- You need ongoing capacity rather than a deliverable. That's closer to a retainer or staff augmentation.
A team that tells you this, rather than quoting fixed price for everything, is usually one that has thought about how the work will actually go.
At orithLabs we price Flutter MVPs as fixed-price milestones you can stop between, agreed before code is written, with weekly written updates and your repository and accounts from day one. The two founders who scope the work also write it. If you have a product in mind, our mobile development page has more on how we work, and a first call is free.