"What does an app cost?" — an honest answer
Anyone who quotes a number for this either knows your scope or is planning to invoice you again later. Here is how to tell the difference.
It is the most common question we get, and the hardest to answer. "How much does an app cost?"
The honest reply is that the question is incomplete. It is like asking what a building costs. How many floors, how many square metres, where, built from what?
But left there, that answer sounds evasive. So let us go one step further: here is exactly what determines the number.
The six things that set the price
Screen count and complexity. The difference between a five-screen app and a forty-screen app is not eight times — it is more, because complexity compounds as screens start depending on each other.
User roles. An app where everyone sees the same thing and an app where admins, staff and customers see different things are not the same job. Every role is another flow and another testing burden.
Whether there is a backend. If the app only displays data, the work halves. User accounts, stored records, notifications and reporting mean a server side is being built too.
Integrations. Payments, invoicing, shipping, an existing ERP. Each one is an unknown: is their documentation any good, is there a test environment, will anyone answer support requests? This is where most surprises come from.
Offline support. "It should work without a connection" raises the cost significantly. Keeping data on the device, resolving conflicts and syncing is an engineering problem in its own right.
Whether the design exists. With an approved design, development starts immediately. Without one, that work happens first.
What a number quoted before scope actually means
There are two possibilities:
It is high. You are getting a quote with the uncertainty priced in. If the work turns out to be simpler, the difference does not come back to you.
It is low. Once work has started, the "that was out of scope" conversations begin. A budget argument mid-project damages both the schedule and the relationship.
Both are bad. This is why we define scope first.
How it should work
A healthy quoting process looks like this:
- A conversation. We listen to what you want to build. Free, no obligation.
- Scoping. The work is broken into items: which screens, which roles, which integrations, and what is not in the first release.
- A written quote. Time and cost per item — including what is excluded. That is where disagreements actually come from.
- Development. A working build shown at regular intervals.
The exclusions list in step three is the most valuable part of the quote. Lines like "content entry is not included", "store accounts opened in the client's name", "two rounds of design revisions" settle the argument you would otherwise have in six months.
If you have a budget, say it
Most people think naming a budget weakens their position. The opposite happens.
If we know the budget, we can tell you what fits inside it — which features make the first release and which move to a second phase. If we do not, we either scope too broadly and inflate the number, or misjudge and quote wrong.
"I have this much, what can be built for it?" gets to an answer far faster than "how much does it cost?"
Starting small is not a shortcoming
The first release does not have to do everything. A version that does the core job and reaches real users is cheaper, and it lets you make the next decisions from measurements rather than guesses.
On some projects our first job is to narrow the scope. It shrinks our own invoice, but it increases the number of projects that actually get finished.