Powstania Warszawskiego 15
31-539 Kraków
The most common objection to fixed price app development is that every change becomes a paid change request. That happens, but mostly in contracts that never defined what a change is. This guide shows how to tell a change from a defect, what a proper change request contains, and how to keep them rare.
In a fixed price app project, a change request covers only work outside the agreed scope, such as a new feature, user role or integration. It must state the change, the price and the timeline impact, and it starts only after the client approves it in writing. Defects in agreed features are not change requests: fixing them is the agency's responsibility. Clarifications of details the scope left open should usually be absorbed without extra cost. A written scope with explicit exclusions keeps change requests rare.
Fixed price moves the risk of underestimating from the client to the agency. The agency commits to a result for a price, and if the work takes longer than planned, that is its problem. For a founder or an operations manager planning a budget, that is the main appeal.
The reputation problem comes from contracts where the scope is vague. When the specification says "user management" without saying which roles, which permissions and which screens, every detail becomes a negotiation. An agency protecting its margin will call many of those details changes. A client protecting their budget will call them obvious parts of the original deal.
Both sides can argue it in good faith, which is exactly why it gets expensive.
The fix is not a different pricing model. It is a clear definition of what counts as a change, agreed before the build starts. You can see how we structure this on our fixed price app development page.
Every request that comes up during a project fits into one of three categories. Agreeing on them up front removes most of the arguments later.
Something in the agreed scope does not work as described. The agency fixes it at its own cost, during the build and during the warranty after acceptance.
The scope left a detail open, such as the order of fields on a form or the wording of a notification. Deciding it does not add new functionality, so it should not add cost.
New functionality or a different behaviour than agreed: another user role, a new integration, a new payment method. This is where a change request belongs.
The middle bucket is where good and bad agencies differ most. If every clarification arrives with a price attached, the scope was either too thin or the agency is using it to recover margin. Everything agreed in the fixed price scope should simply work, and making it work is the agency's job, not a new invoice.
Abstract definitions only help so far. These are the kinds of requests that come up in almost every app project, and where they usually land.
Notice that timing matters. The same request is cheap when it arrives while screens are still designs and expensive when the feature is already built and tested. That is the strongest argument for approving designs before development starts.
A change request is a small contract amendment. If it arrives as a line on an invoice, the process has already failed. Before any work starts, you should receive a document that answers these questions.
What changes. A plain description of the new or different behaviour, written so that someone outside the project could test it.
Why it is a change. A reference to the part of the scope it goes beyond, or to the exclusion it touches.
Price. A fixed amount for this change, not an hourly estimate that can grow.
Timeline impact. Whether it moves the milestone or the launch date, and by how much.
Where it fits. Whether it goes into the current milestone, a later one, or the next stage after launch.
Approval. A written yes from the client. No approval, no work, no charge.
The "where it fits" line is the one most often skipped, and the one that protects launches. Many changes are genuinely good ideas that simply do not need to delay the first release.
A project with zero change requests usually means the client stopped learning. A project with dozens usually means the scope was not ready. The goal is a small number of deliberate ones.
If the scope still feels thin before signing, a short discovery workshop is cheaper than the change requests it prevents. Our guide on whether you need a discovery workshop helps decide.
You can often predict how change requests will be handled before the project starts, just by reading the offer.
A fixed price project ends with a formal acceptance. Both sides confirm in a signed protocol that the agreed scope was delivered, much like the acceptance of a machine or a building. From that point, the three buckets still apply, but the timeline changes.
Defects in accepted features are covered by the warranty. On larger contracts we give a one year warranty on the software. Changes after launch become the next stage, usually planned and priced as a new fixed scope based on what real users do. Code ownership should transfer to you with the final payment, which the contract should state clearly; we cover that in detail in fixed price app development contracts.
For startups, this staged approach is usually the healthiest one: a focused first version under a fixed price, then the next stage shaped by data. We describe it in fixed price MVP development and on the MVP development for startups page. Current price ranges are on the pricing page.
A change request is a written proposal to add, remove or alter something that is outside the agreed scope. It describes the change, its effect on the price and the timeline, and it takes effect only after the client approves it. Fixing something that was in the scope but does not work is not a change request, it is a defect the agency has to fix.
The client pays for new scope: features, roles or integrations that were not in the agreed specification. The agency pays for defects: anything that was agreed but does not work as described. Clarifications of details the specification left open should normally be absorbed by the agency as long as they do not add new functionality.
You cannot avoid all of them, but you can reduce them. Agree a written scope with an explicit list of exclusions, approve clickable designs before development starts, test each milestone on your own phone, and move new ideas into a version two backlog instead of the current build.
It is possible when the agency agrees, but it is rarely the best fix. A more common approach is to finish the agreed fixed price scope, accept it, and run the next stage under a new fixed price or a different model once real usage shows what the product needs.
That depends entirely on the change. Moving a button costs close to nothing, while adding a new user role touches the app, the backend, the admin panel and the tests. A good change request states the exact price and timeline impact before any work starts, so there are no surprises on the invoice.
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 what you have, even if it is rough. We will turn it into a written scope with features, exclusions and milestones, so you know exactly what the fixed price covers before anything is signed.