Cost, scoping, and briefs
Fixed price vs time and materials: what to put in the contract
Part of the guide: Mobile App Development Cost: How to Break a Quote Into Parts
Fixed price vs time and materials is settled by the maturity of your scope, not by the size of the project. If you can write out a closed list of features and nobody inside the company objects to it, a lump-sum quote makes sense. If half the answers only arrive after the first few weeks of work, a fixed sum buys you the appearance of certainty plus an amendment for every change. What follows is not a verdict on which model wins — it is the list of clauses to demand so the model you pick does not surprise you later.
What decides the choice: scope maturity, not project size
The billing model is matched to how many unknowns are left on the day you sign. A large rollout with a precisely described scope can be settled as a lump sum; a small app built on an untested product idea usually cannot, because the first version will change anyway once real users touch it.
Test it against your own document: if your software project brief lists roles, user paths, the systems to integrate with by name and version, and a separate list of exclusions, the scope is mature. If what you have instead is a wish list, first decide what belongs in the MVP scope, and only then discuss the model.
The second criterion is your own availability. Hourly billing needs a decision-maker on your side who prioritises tasks and answers within a day or two. Without that person you are paying for a team waiting on decisions.
Fixed price vs time and materials: who carries the risk of a wrong estimate
The models differ in one thing: who pays when the work takes longer than the estimate said. Fixed price is a lump sum for a scope defined up front — the studio carries the risk. Time and materials bills the hours actually worked and the resources actually used — the risk stays with you. The third model, called fixed budget in Polish IT projects, is hourly billing under a budget cap that allows scope changes without separate orders; all three are listed by mobitouch.net in a piece dated 1 February 2024.
| Model | Who carries the estimate risk | When it works | What the contract must contain |
|---|---|---|---|
| Fixed price | The studio — which is why it protects itself with a reserve in the price | Scope closed and described, few technical unknowns | Scope annex, list of exclusions, change-request procedure with a pricing deadline, acceptance criteria per stage |
| Time and materials | You — you pay for the hours actually worked | Scope discovered along the way, priorities shifting every few weeks | Time reporting broken down by task, a duty to raise an alert when an overrun is forecast, the right to suspend work, a notice period |
| Fixed budget (hours under a cap) | Shared: flexible scope, hard ceiling on cost | You know the goal and the budget but not yet every feature | Maximum amount, alert threshold, a swap rule (a new feature enters as another leaves), how consent to exceed the cap is given |
The label on the offer matters less than the clauses underneath it. An hourly contract with no cap and no reporting is far riskier for you than the same contract with one extra paragraph.
Why a lump-sum quote carries a reserve, and what that does to the price
Under fixed price the studio cannot top itself up later for a mistake in the estimate, so it prices a reserve into the offer. In its piece of 1 February 2024, mobitouch.net reports that the buffer added to a fixed price quote runs at around 30% and is meant to cover unforeseen circumstances. That is the finding of one publication rather than an industry standard — but it shows the mechanism clearly.
The practical consequence: the reserve grows with every unknown you leave in the request for proposal. Each “we do not know yet whether our system has an API” and every missing exclusion list gets priced. What else the number in an offer is made of is broken down in the guide on mobile app development cost.
When you review the offer, force two things: an out-of-scope list, and an answer on whether project management, testing, post-launch support, and tool licences sit inside the price. Those four items are the ones that most often come back later as an extra cost.
The change-request procedure: who raises it, who prices it, by when
A change request is a formalised path for raising a scope change together with its estimate and the decision on it — and that path, not the name of the model, decides whether the project runs without disputes. The contract should cover six points:
- Who raises it. Named people on both sides, plus the form of the request (a document or the task tracker), so changes do not come into being over the phone.
- Who prices it and by when. A deadline counted in business days from the request, five for example — without it, pricing a change can block work for weeks.
- What the estimate contains. Effort, the effect on the schedule, and which tasks have to move or drop if the budget is to stay unchanged.
- Who decides and by when. One decision-maker and a deadline for approval, after which the request expires.
- What happens to the schedule. A rule that an approved change automatically shifts the following milestones by the agreed number of days.
- What happens without approval. Work continues under the existing scope and the request goes into a change register, to be revisited when the next stage is planned.
On top of that come the performance safeguards. Polish law firms list, among the standard elements of an IT implementation contract, the delivery methodology, an acceptance procedure with a Definition of Done, the transfer of economic copyright or a licence, the remuneration, an NDA, safeguards such as contractual penalties, a deposit and substitute performance, an exit plan, subcontracting rules, and termination terms (umowywit.pl). Contractual penalties there work as liquidated damages, so you do not have to prove the size of the loss. Ownership of the code is covered separately in the guide on who owns the code — and note that when you contract a Polish studio, Polish law governs how that transfer has to be made. This material is information, not legal advice — agree the exact wording of the clauses with a lawyer.
Acceptance: without acceptance criteria you cannot close a stage
Acceptance only works if you wrote down beforehand what “done” means. A Definition of Done is the list of conditions every task has to meet to count as finished: tests pass, documentation exists, the build runs on a test environment. Acceptance criteria apply to a specific feature and describe the behaviour you check during acceptance.
Work usually runs in two-week sprints, and the review at the end of a sprint is the natural moment for partial acceptance. Under fixed price those reviews protect you from a mismatch surfacing only at final acceptance, when fixing it means an amendment.
Agree as well what exactly you are accepting beyond a working system. The documentation handed over by the studio should cover the source code, the specifications, and the user and developer documentation. That is the material that makes the exit plan in your contract executable rather than declarative.
When fixed price is imposed from outside
Sometimes the model is not a choice at all. In grant-funded projects the budget from the application is fixed, so a lump sum can be the only workable form of settlement (mobitouch.net, 1 February 2024). The same goes for purchases where the amount was approved in an annual budget and cannot be increased during the year.
In that setup, flexibility moves from the budget to the scope. Instead of negotiating the amount, put a swap rule in the contract: a new feature can enter the stage if another of comparable effort leaves it, with the project manager keeping the register of those swaps. A fixed sum then stops meaning a fixed product.
Sentences worth pasting into your request for proposal
The billing model can be settled before the contract if your request asks for the right information. Swap in your own names and send the paragraph below to every studio you approach, in identical wording.
"Please quote in two variants: a lump sum for the scope in the annex, and hourly billing under a budget cap for the same scope. For the lump-sum variant, state the assumptions you made and the parts of the scope that raise the reserve in your estimate the most. Please also include an out-of-scope list and say whether project management, testing, post-launch support, and tool licences are inside the price. In your reply, describe your change-request procedure: the form of the request, the deadline for pricing it in business days, the effect on the schedule, and what happens when a change is not approved. Please state the acceptance criteria for a stage and the scope of documentation handed over at acceptance."
Two variants of the same estimate are the cheapest test you can run. The gap between them shows how the studio reads the uncertainty in your project, and the answer on the change-request procedure tells you whether it has run projects where the scope actually moved. If you would rather work through the goal, the scope, and the constraints with someone first, start that conversation with us before the request goes out.
Checklist
Decide whether your scope is closed and written down before you pick a billing model.
Put a change-request procedure in the contract: who raises it, who prices it, within what deadline, and who decides.
Demand acceptance criteria per stage and a shared Definition of Done.
With hourly billing, set a budget cap and the threshold at which the studio has to raise an alert.
Require an out-of-scope list in the offer, and check whether project management, testing, post-launch support, and tool licences are inside the price.
Check that the contract settles the transfer of economic rights to the code, or a licence to it.
Agree what documentation is handed over at acceptance: source code, specifications, user and developer documentation.
Write the exit plan and the termination terms while you still do not need them.
Frequently asked questions
- Fixed price vs time and materials: which is safer for the client
- Neither model is safer in itself, because each parks the risk somewhere else. Fixed price gives you a predictable sum, but the studio absorbs the risk of a wrong estimate and prices it in, and every scope change needs an amendment. Hourly billing gives you flexibility, yet you are the one who pays for an underestimate. Safety comes from the clauses rather than the label: a change-request procedure with deadlines, acceptance criteria per stage, and a list of exclusions.
- How large is the buffer a studio adds to a fixed price quote
- There is no single binding figure, because the reserve depends on how many unknowns are left in the scope. In a piece dated 1 February 2024, mobitouch.net reports that studios add a contingency of around 30% to a fixed price quote to cover unforeseen circumstances. That is a number from one publication rather than an industry norm — use it as a reference point and ask directly what reserve sits in your offer and which parts of the scope push it up.
- Who pays for a scope change mid-project
- It depends on whether the change fits inside the agreed scope or extends it. Under fixed price a new feature usually means a separate estimate and an amendment, because the original sum covers only what the scope annex lists. Under hourly billing the change simply consumes budget, so its cost shows up in the report. That is why the contract should describe the change procedure: the form of the request, the deadline for pricing it, the effect on the schedule, and what happens when it is not approved.
- What does the acceptance procedure look like and what is a Definition of Done
- A Definition of Done is a written list of conditions a task has to meet before it counts as finished — for example passing tests, having documentation, and being deployed to a test environment. Acceptance means checking the result against that list and against the acceptance criteria agreed for the stage. Polish law firms list an acceptance procedure with a Definition of Done as a standard element of an IT implementation contract (umowywit.pl). The natural moment for partial acceptance is the review at the end of a sprint.
- Is it worth putting contractual penalties for delay in the contract
- Contractual penalties work as liquidated damages, so their advantage is that you do not have to prove the size of the loss (umowywit.pl, describing Polish contract practice). They are one of several performance safeguards, alongside a deposit and substitute performance. Expect the studio to price that risk and reflect it in the offer, and note that with a moving scope the dispute is usually about whether the delay came from the work itself or from waiting on your decisions. This is information, not legal advice.
- What should I do when the project blows the budget halfway through
- Start by establishing what actually consumed the budget: work from the original scope, changes raised along the way, or time spent waiting and reworking. Ask for a list of completed tasks and a forecast to the end of the stage, then make a scope decision rather than a money decision — which features must work in the first release and which drop out. For the future, the protection is a budget cap in the contract plus a threshold above which the studio has to raise an alert.
Sources and methodology
These links lead to primary sources and the rules we use to prepare and update our material.