Insights · Pricing · 8 July 2026
What does an app cost to build?
It is the first question on almost every call, and most of the industry avoids answering it. Here is the honest version, from a studio that puts a fixed number on paper.
A founder we met last year had collected five quotes for the same app. The lowest was four thousand dollars. The highest was one hundred and eighty thousand. Same one page idea, same deadline, a forty five times difference in price.
She asked us the obvious question: which quote was the lie? The honest answer was all of them and none of them, because a price for "an app" means nothing until somebody defines the app. That conversation is what this post writes down.
Why nobody gives a straight answer
Ask five agencies what an app costs and you will get five day rates, which is not an answer. A day rate tells you the price of time, not the price of your app, and it quietly moves every risk onto you: if the build takes longer, you pay more, and the people who estimated the work are the same people being paid by the day to continue it.
There is a second reason the industry avoids the question. Agencies do not want to be the first number on the table, because the first number anchors the negotiation. So the answer arrives as "it depends," which is true, useless, and profitable, in that order.
The honest answer has a shape, not a single number. A focused first version of a consumer app is a small experienced team working for between two and twelve weeks. Where you land inside that range is decided by a handful of things you control, and that is the useful part.
The four things that actually drive the cost
Scope, measured honestly. Not the number of screens, and not the number of features: the number of features that must be correct on day one. An app with one loop done beautifully costs less and performs better than an app with nine features done adequately. When we cut a project's cost meaningfully, this is almost always where the cut happens, and the product is usually better for it.
Platforms. Building iOS and Android together roughly doubles the surface before anyone has proven that people want the thing. One platform first is almost always the right call. The second platform is cheaper to build once the first one has taught you what the product really is.
Integrations. Payments, sign in, data sync, and anything that talks to another company's system cost more than screens do. The reason is unglamorous: the failure cases take longer than the happy path. A payment that succeeds is an afternoon. A payment that fails halfway, retries, and must never charge twice is a week.
The unknowns you bring. An existing codebase, a legacy backend, a compliance requirement. None of these are disqualifying, and all of them belong in the first conversation, because a surprise priced in week one is cheap and the same surprise discovered in week eight is not.
What the ranges look like in practice
For orientation, not as a quote: a marketing website runs two to six weeks of work. A web application with accounts and real data runs four to ten. A native consumer app with one well built loop runs six to twelve. Multiply by the size and location of the team you hire and you have the honest bracket for your project.
The bracket is wide because the decisions above are yours. Two founders with the same idea can land at opposite ends of it, and both can be right: one is buying a test, the other is buying a launch.
How we put a number on it
We price by phase, fixed, in writing, after the first call. A phase is a clearly defined scope with a demo every Friday, and the quote is the price whether the work takes the estimated time or longer. That moves the estimating risk to the people best placed to carry it, which is how it should work.
If the scope is genuinely uncertain, we say so and start with an advisory sprint instead: one to two weeks, a fixed small price, and a written plan you keep whether or not we build together. It is the cheapest way to turn a vague idea into a quotable one.
Changes mid build are normal and are quoted the same way: priced and agreed in writing before they are built. The result is that the number you said yes to is the number you pay, and every exception was your call.
The question to ask instead
Do not ask "what does an app cost." Ask "what does the first version of my loop cost, on one platform, with these two integrations." That question gets real answers, because it is a real question. Any studio that cannot answer it with a fixed number is telling you how it bills, and that is worth knowing before you sign anything.