Powstania Warszawskiego 15
31-539 Kraków
A fixed price only protects you if both sides agree on what "done" means. Fixed price app acceptance is where that agreement is tested. It is also one of the first questions experienced buyers ask on a call, and one of the least explained parts of app development.
In a fixed price app project, acceptance starts before the contract: each feature in the scope gets a written criterion describing what a user can do. Every stage is then shown on a working build and accepted against those criteria. At the end, your own team tests the app in real conditions, remaining issues are listed and fixed, and the project closes with a signed acceptance protocol. A warranty period follows, during which anything agreed in the scope that does not work is fixed at the agency's cost.
A fixed price contract trades flexibility for predictability. The agency commits to a price for a defined scope, and you commit to that scope. The weak point is the word "defined". If a feature is described as "user profile", the agency may build a name and a photo while you expected verification, privacy settings and a public view.
Acceptance is the mechanism that makes the scope concrete. It turns every line of the offer into something both sides can check on a real device. When it is done well, disputes about what was promised mostly disappear, because the answer is written down. When it is skipped, the fixed price becomes a negotiation that starts at the end of the project, which is the worst moment for both sides.
Good acceptance criteria describe behaviour, not screens. They answer one question: what can a user do, and what happens when they do it.
"Booking module." "Notifications." "Admin panel for users." Each of these can be delivered in a day or in a month, and both versions would match the description.
"A client can book an available slot, receives a confirmation and a reminder the day before, and can cancel up to the cutoff set by the admin." One test, one answer.
You do not have to write these yourself. A good agency drafts them from the discovery workshop and asks you to correct them. Your job is to read them as a user would and ask "what happens if" until the answers stop surprising you. We describe how the scope document is built in mobile app requirements document.
In a well run project you see a working build every one or two weeks, not a presentation. Each build covers a piece of the scope, and you check it against the criteria while the context is fresh.
The sorting in the third point is the most important habit in a fixed price project. We cover what happens to the ideas list in change requests in a fixed price project.
TimeFix is a field service product where technicians log working time on jobs. During tests by the people who actually use it, one requirement appeared that was in no document: the work timer had to keep running when a technician locked the screen or took a call from inside the app.
It is obvious once you see a technician on a real job, and invisible in a meeting room. Catching it before final acceptance made it a normal fix instead of a dispute after launch. More on this type of product in custom HVAC software Development.
Once the full scope is delivered, the decisive round begins. Your team uses the app the way it will be used after launch: on their own phones, with real data, in the places where the work happens.
This round regularly surfaces things that work perfectly in a simulator and fail in the field. Connection drops, location accuracy, battery behaviour, how a screen reads in sunlight. None of them is anyone's negligence. They are simply impossible to see without the real environment, which is why final testing by your team is part of acceptance and not an optional extra.
The output of this round is a single list. Each item is marked as a defect against the scope, which the agency fixes before sign off, or as a change, which you can schedule for a later stage.
Liniowiec is a river navigation app built in Flutter. In the simulator everything worked. The confidence that the system really worked came only when the app was taken out on the water: the first tests there showed lost connections and an incorrect position on the map.
Both had to be solved before the app could be trusted on the water, and neither could have been found at a desk. That is the purpose of final testing in real conditions: problems found by your team during acceptance cost a build, while problems found by users after launch cost reputation. More on building for weak connectivity in offline first app development.
The project closes with a signed acceptance protocol. Companies that buy machinery or commission a building already know the idea, and it works the same way for software. The document is short and states four things.
Handover deserves attention of its own. Store accounts and cloud projects should be registered to you from the start, not transferred at the end. If you plan to continue development with your own developers later, our guide on MVP codebase handover lists what to request.
The warranty is where the line between a defect and a change matters most. The rule we work with is simple: everything agreed in the fixed price scope has to work, and fixing it is our responsibility. On large contracts that comes with a one year warranty on the software.
A feature in the scope does not work as its criterion describes. Fixed at the agency's cost, before and after acceptance.
The feature works as described, but you now want it to work differently. Priced and scheduled as new work.
Apple or Google change requirements after launch. Handled as maintenance, as described in mobile app maintenance services.
Acceptance is the moment when delays on the client side become visible, and the most common cause we see is simple: accounts and access arrive too late.
With these in place, acceptance is a few focused weeks rather than a negotiation. Our fixed price app development page shows how we structure scope, stages and acceptance from the first call, and fixed price MVP development applies the same model to a first version.
Acceptance criteria are written into the scope before the contract is signed. Each stage is shown on a working build and accepted against those criteria. At the end, your own team tests the app in real conditions, open issues are listed and fixed, and the project is closed with a signed acceptance protocol, followed by a warranty period.
A short signed document that closes the project. It confirms which scope was delivered, lists any remaining issues with the deadline for fixing them, and marks the start of the warranty period. It is the same idea companies know from buying machinery or a building.
If something agreed in the scope does not work as described, fixing it is the agency's responsibility, both before and after acceptance, within the warranty period. If the app works as agreed but you want it to work differently, that is a change and is priced separately.
Both. The agency tests every build before you see it. Your team then tests the app the way it will really be used, on real devices and in real conditions. That second round is where requirements surface that could not be written down in advance.
Yes, if it does not meet the criteria written in the scope. That is exactly why the criteria have to be written before work starts. Refusing because you would now like something different is a change request, not a failed acceptance.
Thomas sets the company's long term strategy and direction, identifies market opportunities, and owns business development and client acquisition. He builds strategic partnerships that last beyond a single project. He works with clients from the first strategy conversation, so their business goals, not just their feature list, drive every decision.
Send us your idea or an existing scope. We will show you how we would write the acceptance criteria and split the project into stages you can accept one by one.