Powstania Warszawskiego 15
31-539 Kraków
A fixed price is easy to promise and hard to keep. The number on the first page is not what protects a founder with limited runway. What protects the budget is the part of the document that says what counts as finished, what happens when the scope moves, and who pays when something agreed does not work. Four clauses decide that, and most quotes leave at least two of them open.
Fixed price means the supplier takes the estimation risk. If the work takes longer than expected, the supplier absorbs it. That is the whole trade, and it is a good trade for a company that has a finite amount of money and needs a working product at the end of it rather than a burn rate.
The trade only works in one direction though. The supplier can carry the risk of a scope being harder than it looked. No supplier can carry the risk of a scope that keeps changing. So a fixed price contract is really a scope contract with a number attached, and every weak clause in it is a place where the number stops meaning anything.
That is also why a serious supplier asks uncomfortable questions before quoting. We would rather spend two calls narrowing what version one does than write a confident number against a paragraph of description. The commercial model we use is described on the fixed price app development page, and the ranges sit on the pricing page.
These are the four places to read carefully in any quote you receive, including ours. Each one has a simple test you can apply in a minute.
The scope annex should let a stranger count things. How many user roles. How many screens or flows. How many integrations, named. How many languages. Which platforms. What the app does when there is no connection.
The testCould a different developer build from this document without calling you.
Acceptance should be a written checklist tied to the scope, run together, with a fixed window for reporting issues. Release to the store is a milestone, not an acceptance criterion, because store review says nothing about whether your process is covered.
The testIs there a document you both sign that says which items were verified.
Anything inside the agreed scope should work, and fixing it afterwards is the supplier's cost, not a support package you buy. Ask how long that runs and what is excluded. We run a one year warranty on the agreed scope and treat it as part of delivery.
The testAsk whether the warranty is included or sold as a retainer.
Changes are normal. What matters is the route. Either a separately priced annex with its own effect on the date, or a decision to push the item to version two. A contract without that route turns every new idea into an argument.
The testDoes the document say who approves a change and how the date moves.
Two of these four are usually missing from quotes founders show us. Acceptance goes missing most often, and it is the one that costs the most later, because without it both sides argue from memory.
A fixed price without a written acceptance list is an estimate that both sides will remember differently.
Quotes rarely fail on the hard technical parts. They fail on sentences that looked harmless during the sales conversation and turned out to hold a month of work each.
Founders ask whether fixed price or time and materials is better. The honest answer depends on how much certainty you need and how settled the product is, not on which model is more modern.
Fixed price fits a defined first version. You know the job the product does, you have a date that has a reason behind it, and you need to know the total before you start. Most first releases sit here, including the field tools and booking products we build.
Time and materials fits continuous work. The product is live, priorities change monthly, and the value comes from reacting rather than from a defined scope. Paying for a fixed scope here just buys a slower version of the same thing.
A dedicated team fits a company with its own product direction. You have someone deciding what gets built, and you need capacity rather than a delivery. That is a different contract with different risks, and it is not cheaper by default.
If you are working from a finite amount of money, the important number is not the quote. It is what you will own on the day the money runs out. A fixed price contract with a real scope annex answers that on day one. An hourly contract answers it only in hindsight.
We cannot price a description, so the work before the quote is where the accuracy comes from. It usually takes a few days and it is the same sequence for a marketplace, a booking product or a technician tool.
For founders who want that sequence run properly before committing, the discovery workshop does it as a paid, separate piece of work with its own deliverable, so the output is usable even if you take it to a different supplier.
If you already have a rough scope and a date, send it over by email. We reply with a written version one scope, the counts behind it and a fixed price, with no sales call in between.
Send your scope by emailYes, as long as a scope is written first. The specification does not have to arrive from the client. More often it is written during scoping, based on how the work happens today, and that document becomes the annex the price is attached to.
Developer accounts and access to existing systems, not code. Company verification on the Apple side can take weeks. Opened in the kickoff week it costs nothing. Opened before release it can cost a month.
It becomes a separately priced annex with its own effect on the date, or it moves to version two. Both routes are fine. What breaks a project is adding work informally and expecting the original date and price to hold.
It means the scope is decided earlier. Quality problems come from unclear acceptance criteria and no client testing during the build, which can happen under any model. Ask how acceptance is verified and how often you will see working software.
The accounts should belong to your company from day one and the code should be handed over with repository access. Both are worth confirming in the contract rather than at the end of the project.
It depends on the shape of the product rather than the contract model. The ranges and what moves them are set out in the mobile app development timeline.
Thomas Siudut
Co-Founder and CEO, Apps Value
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.
Email works best if you already have a description. If you would rather talk it through first, a short call covers the same ground.
30 minutes, no preparation needed.