Fixed price software development: when it works and when it fails

"Should we sign a fixed price or pay by the hour?" If you are about to hire a team for your app, this question decides who pays when the work takes longer than planned. This article tells you when a fixed price protects you, when it turns against you, and how to set up a contract where the number you sign is the number you pay.

Short answer: a fixed price works when the scope is frozen before the price is set, and fails when the price is a guess about a vague idea. We fix the price for one milestone at a time, after a 1-2 week planning step called Prototype to Plan. You know every price before it starts, and you can stop after any milestone and pay only for finished work.

In 2022 we published a post called "Why fixed price is a big no-no". Its point still stands: a fixed price on a vague scope is a trap. What changed is how we remove the vague part before anyone names a price. This article replaces that post.

What is fixed price software development?

In short: in fixed price software development, the team agrees on the scope, the price and the time before work starts, and the price does not change if the work takes longer. The other common model is time and materials, where you pay for the hours worked. A third option sits between them: a fixed price for each milestone.

A milestone is a piece of the app you can see and test, such as "sign-in and the main flow on your phone". Each one ends with something working, not with a report.

When does a fixed price fail? When the scope is a guess

In short: a fixed price fails when it is set before anyone knows what exactly will be built. Then the price is a guess, and a wrong guess hurts you either way. This is what our 2022 post warned about, and it is still true.

• A guess that is too high. The team adds a buffer for everything it cannot see yet. You pay for risks that never happen.
• A guess that is too low. When the money runs out before the work does, the team rushes. Quality drops, tests get skipped, and you find out after launch.
• Every change becomes a fight. A detail nobody wrote down turns into a change request and an argument about whether it was "in scope".
• A plan that is out of date at signing. A long specification written months before the build often describes an app nobody wants by the time it ships.

The problem is not the fixed number. The problem is a fixed number for a picture nobody has seen yet. Fix the picture first, and a fixed price starts working for you.

When does a fixed price work? Four conditions

In short: a fixed price works when four things are true: the scope is something you can click, the price covers a small piece, you can stop between pieces, and the team has shipped apps of your size. Miss one, and you are back to a guess.

1. The scope is frozen in screens, not in words. A clickable prototype and a full screen list leave far less room for "I thought it would..." than a written specification.
2. The price covers one milestone at a time. A two or three week milestone is easy to estimate. A six month project is not.
3. You can stop after any milestone. You pay only for finished work, so a wrong turn costs one milestone, not the whole budget.
4. The team has done it before. Ask for real apps at your size, with the screens to prove it.

How does a fixed price per milestone work? An example $25k app

In short: the build is split into milestones of 2-3 weeks, and each one gets its own fixed price before it starts. Our MVP / App Launch starts from $15k, is typically $15-50k, and takes 8-12 weeks. Here is how an example $25k project splits.

• Weeks 1-2Prototype to Plan, $5k. Scope frozen, key screens designed and clickable, a price for every milestone, the list of risks.
• Weeks 3-5Design system and core flow, $6k. Your app's look and its main flow, on your phone.
• Weeks 6-8Backend, accounts and payments, $6k. Sign-in, data on your own cloud account, payments or subscriptions.
• Weeks 9-10Admin panel, $4k. Manage users and content, or ask Claude or ChatGPT about your data through MCP, a standard that lets AI assistants use your app's data.
• Weeks 11-12Polish and store release, $4k. Testing, accessibility, the store listing and the release in the App Store and Google Play.

This is an example: your milestones and prices come out of Prototype to Plan. You get a new build on your phone every week, so you see each milestone take shape before you pay for the next one. Payment is a deposit of half the first month's work, then per milestone. Apps we build come with a 6-month guarantee. Every price is on our pricing page.

What if you want something new in the middle of the build? It gets its own price before anyone starts on it, so you decide with the number in front of you, not after the invoice.

Why do we set the price only after Prototype to Plan?

In short: because a price is only as good as the picture behind it. In 1-2 weeks of Prototype to Plan, you click through your key screens on your phone, the scope gets frozen, and every milestone gets a fixed price. It costs $5k, credited 100% to the build, and if you do not build with us, you take the plan to any team.

Case study: Prenta clicked 195 screens before the build got its price

The problem. Erika, Prenta's founder, came to us with an idea for a household to-do app and an AI prototype. A prototype like that shows the idea, but not what the app must really do, so any price set on it would have been a guess. What we did. We clicked through 195 prototype screens with her in four rounds and kept the best 10. Those 10 screens became the scope. The result. One team built six parts on that scope: the iOS and Android app, the backend, an admin panel her team edits in chat, a calendar agent, the emails and the website.

Museo went the same way: we explored 49 home screen variations before the build. Read the whole story in the Prenta case study, and more on starting from what you already have in Your prototype is the best brief.

When is time and materials the better choice?

In short: when the work has no fixed end and your own team decides what comes next every week. Then a fixed price would need a new estimate every few days. Paying by the hour is simpler, as long as someone on your side leads the work.

• Your product team needs more hands. Developers join your team, work in your tools and follow your priorities.
• The app is live and changes every week. Small changes, experiments and fixes, with no single end point.
• Research with an unknown outcome. When nobody can say what will work, pay for the time and decide as you learn.

For this we offer Team up: senior Flutter developers in your team at $60/h, minimum 120 hours a month, with 2 weeks notice. Three of our Flutter developers joined Fitatu's team this way. Details on our team augmentation page. For a new app with a budget cap, a fixed price per milestone is usually safer: you know the number before work starts.

What should you check before you sign a fixed-price contract?

In short: check that the price covers a scope you can see, that you can stop, and that what is built belongs to you. Seven questions cover it, and a good team answers each one in a sentence.

1. Is the scope written as a screen list or a clickable prototype, not only as a description?
2. What exactly ends each milestone, and what does each one cost?
3. Can I stop after any milestone and pay only for finished work?
4. How is a new idea priced in the middle of the build?
5. Are the store accounts, the cloud account and the code repository in my company's name from day one?
6. What is the guarantee after launch, and how long does it last?
7. Which apps of my size have you shipped, and can I see them?

Want to know what your app would cost before you talk to anyone? Use our two-minute app cost calculator, or read How much does it cost to build an app in 2026? The whole process, from the first call to the store, is on How we work.