Powstania Warszawskiego 15
31-539 Kraków
Two proposals for the same app, one twice the price of the other. Almost always they are quoting different work, and the difference sits in what neither document says out loud. Here are ten checks that expose it, what a good answer looks like, and what a bad one sounds like.
Eight things: a written scope with its exclusions, named assumptions, a timeline with conditions attached, QA and store release as visible work, a stated warranty period, a change process, a list of what you receive at handover, and a clear statement that the code and store accounts are yours. A proposal missing three or more of these is not cheaper, it is smaller.
Read each check against the document in front of you. You are not looking for perfect answers, you are looking for whether the question was considered at all. Four or more warning signs in one proposal predicts a difficult project more reliably than any price comparison.
Usually not obviously bad. It reads as clean, confident and short, and every line sounds reasonable in isolation. Below is a composite of lines we see repeatedly, with the question each one leaves unanswered. None of them is a lie. Each is a decision quietly left for later, when it will cost more to make.
None of these phrases is disqualifying on its own. What matters is whether the document answers the question somewhere else. If four of the ten checks above come back as warning signs, ask for the missing parts in writing before you sign rather than after.
Normalise the scope before comparing the totals. Take the more detailed document, list everything it includes, and ask the other supplier to confirm each line in writing. The gap usually turns out to be design, QA, store release or post launch fixes, and once those are added the two numbers move much closer together.
Take the fuller proposal and turn it into a plain list of deliverables. This becomes the common measuring stick rather than either supplier's format.
In writing, line by line, included or not. This one email resolves most price gaps and shows you how each supplier behaves when asked to be precise.
Anything excluded still has to happen. Add its cost, or add the hours it will take from your own team, and only then compare the two numbers.
If the ranges themselves look unfamiliar, our cost calculator gives you a band to sanity check against, and the reasoning behind it is in the guide to mobile app development cost.
An estimate produced without questions, a document with no exclusions, no mention of what happens after launch, and a timeline that depends on nothing. Each is survivable alone. Two or three together mean the supplier has not thought about your project, only about winning it.
A number produced from a one page brief is a guess dressed as a commitment. The strongest signal of a good supplier is what they asked you before quoting.
Reads as generosity, functions as ambiguity. Every disagreement later will be about something that was implied by one side and not by the other.
Operating systems and store policies change every year regardless of your roadmap. Silence about that period means it has not been priced, not that it is free.
A proposal describes intent. A contract decides what happens when something goes wrong, which is the only moment either document matters.
Five clauses carry almost all of the risk. Ask for them explicitly and treat reluctance on any of them as information about the rest of the relationship.
None of this requires a specialist lawyer to request. It requires you to notice that the words are missing, which is what the list beside this text is for.
We are a mobile development team in Krakow, Poland, building Flutter and React Native products for companies in the United States and Europe. Every one of the ten checks above is something our own proposals are meant to pass, which is the only reason we can publish the list.
Fixed price quoted against a list that names what is out as clearly as what is in, so changes are decisions rather than arguments.
End to end app development After launchOn larger contracts the software carries a one year warranty. Anything inside the agreed scope that does not work is ours to fix.
Maintenance and support Before you signThe wider version of this checklist, covering the first call, the portfolio and the engagement model rather than the document itself.
How to choose a companyBecause they are rarely quoting the same work. The cheaper document usually excludes design, QA, store release or the first months of fixes, and sometimes assumes you supply things you did not know you were supplying. Normalise the scope first and the gap shrinks or explains itself.
Detail is a good signal but not proof. What matters is whether the detail reflects your business or is boilerplate repeated for every client. Look for sentences that could only have been written about your operation, because those come from someone who listened.
Only when the scope is genuinely defined, because the scope list is what makes the price fair to both sides. A fixed price on a vague scope means either you pay for a risk buffer or the supplier quietly narrows what gets built.
Ask for one before signing, in writing. It is a reasonable request and the response is informative on its own. A supplier who can list what is out has thought about the boundary, and a supplier who cannot has not scoped your project yet.
Look for conditions rather than confidence. Eight to twelve weeks from approved scope is a normal range for a defined first version, but the date only holds if decisions and access arrive from your side. Our page on how long it takes to build an app covers what actually moves it.
You can, and a useful answer will tell you what is missing rather than simply that the other one is bad. Read any review with the obvious bias in mind, and give the most weight to comments that name specific gaps you can verify yourself against the document.
Write the missing parts down now and agree them as an addendum, before the disagreement rather than during it. Scope exclusions, ownership of accounts and code, and what happens to defects after launch are the three worth doing first.
Whoever wrote it. I will mark where it is thin, what it assumes without saying so, and what to ask before you sign, whether or not you end up working with us.
Book an intro call