Powstania Warszawskiego 15
31-539 Kraków
An app development estimate looks like one number at the bottom of an offer. Underneath it sit a dozen decisions about scope, risk and assumptions, and those decisions explain why two agencies can quote the same idea so differently. This guide opens the estimate up from the agency side.
An app development estimate is built from a written scope. The scope is split into user roles, flows and screens, backend logic, integrations and requirements such as offline work, and each part is sized by the people who will build it. Testing, store release and project management are added, then the risk of what is still unknown. A good estimate states its assumptions and what is out of scope next to the number. Under a fixed price, that number is what you pay, so the precision of the scope matters more than the size of the figure.
Every estimate we write is built from the same layers. The highlighted ones are where most of the variation between projects, and between offers, comes from.
Each role brings its own screens, permissions and test cases. Two roles are rarely twice the work, more often closer to three times.
The paths a user takes from start to finish, counted, including what happens when something goes wrong.
Accounts, data, notifications and the rules that decide what the app allows. Invisible in a demo, heavy in the build.
Payments, maps, accounting, an ERP or your existing database. A documented API is routine, an old system without one is not.
Only for apps used without a signal. When it applies, it shapes the architecture rather than adding a feature.
Where your team corrects records, manages content and handles exceptions. Small for some products, a second app for others.
Testing on real devices, store submission and the time spent running the project with you. Always present, rarely visible.
What is not yet clear when the number is written. Stated as assumptions, so both sides know where the edges are.
Two offers with the same number can describe different products. Two offers with different numbers can describe the same one. The scope decides which.
Most of the gap between estimates starts with a single line in a brief. Here is the same requirement written twice.
One agency reads one role and a calendar. Another reads two roles, payments, cancellations and reminders. Both are reasonable readings, and their estimates will not be comparable.
Now every agency prices the same thing, and the line can be checked at acceptance. This is what we mean by a scope written with counts.
This is why we do not quote before scoping. The scoping call becomes a written document, and the number is attached to that document rather than to the conversation. Where one part is still genuinely unclear, we scope it separately instead of pricing it blind.
Loopy Jobs is a two sided marketplace built in Flutter with a Supabase backend. Automated payments, company profiles and subscriptions were all reasonable ideas, and all were moved to version two before development started.
That list did more for the estimate than any technical decision. It turned an open ended product into a first version that could be priced, built in two week iterations and checked against the scope at the end.
Sometimes the honest answer to a request for an estimate is a question. If the product still changes shape every week, if one part depends on a system that has never been documented, or if there is no one who can approve the scope, a fixed number would only be a guess dressed up as a commitment.
In those cases we propose a short scoping phase first, or a discovery workshop that produces the written scope. Once that exists, the estimate follows quickly and holds. How that number then turns into a contract is described on our fixed price app development page and in what a fixed price contract has to say.
A serious estimate starts from a written scope, not a conversation. The scope is broken into user roles, flows, screens, backend logic, integrations and non functional requirements such as offline work, then each part is sized by the people who will build it. Testing, store release and project management are added, and the assumptions are written down next to the number.
Usually because they are estimating different products. One offer counts every role, edge case and integration, another prices only the happy path. Compare the scope behind each number before comparing the numbers. Our guide on how to compare app development quotes walks through it.
You can get a range, and it should be treated as one. A fixed number needs a written scope, which is usually produced in a short scoping phase or an app discovery workshop before the contract.
Additional user roles, money moving between parties, integrations with older systems, offline work with data syncing, and an admin panel your team relies on daily. Each of these multiplies screens, rules and test cases rather than adding a single feature.
Every honest estimate accounts for uncertainty, because some requirements only appear once people use the app. Under a fixed price that risk sits with the agency, which is why the scope has to be written precisely before the number is agreed. New work outside the scope is priced separately as a change request.
This article does not quote figures. Current ranges by project shape are on our pricing page.
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, a brief, a list of features or an existing offer. We will tell you what is missing from the scope before any number is written.