“How much does it cost to build an app?” is the most-asked question in software and the least honestly answered. Anyone who gives you a number before a technical conversation is quoting their sales process, not your app. The truthful answer is a framework: what actually drives the cost, why two vendors quote the same brief an order of magnitude apart, and how to get a number that survives contact with reality.
The drivers that actually set the number
Strip away the quote theatre and app cost is set by a handful of decisions, most of them made — knowingly or not — before a line of code exists.
- Scope tier — a prototype that proves an idea, a product real customers depend on, and a platform other systems build on are three different undertakings that happen to share a name. Most cost surprises are a prototype budget colliding with product expectations.
- Platforms — iOS, Android, web, or all of them; native or cross-platform. This choice multiplies or contains everything downstream, including the maintenance nobody has budgeted yet.
- Integrations — every payment provider, identity system, ERP and third-party API brings its own authentication, edge cases and failure modes. Integrations are where “simple” apps stop being simple.
- Compliance and data — handling payments, health data or personal data across borders adds audit trails, retention rules and review overhead to features that looked trivial on the whiteboard.
- The team model — freelancers, a project agency, or a dedicated team carry different cost structures and, more importantly, different risk. The model decides not just what you pay but who pays when an assumption turns out wrong.
Why identical briefs get wildly different quotes
Send one brief to five vendors and the quotes will not cluster — they will spread across an order of magnitude. That is not because four of them are lying. A brief underdetermines the product, and each vendor prices their own assumptions. One is quoting the demo build. Another is quoting the product, with tests, monitoring, error handling and an upgrade path. A third is quoting low on purpose, knowing the gap will come back as change orders once you are committed and switching is expensive. The five numbers are answers to five different questions — and the cheapest one is routinely the most expensive, because underquoting is a customer-acquisition strategy, not an estimate.
Where the cost actually hides
The build quote is the visible fraction. What the app really costs you is decided elsewhere:
- The second year — operating systems update, dependencies rot, app stores change their rules, the backend needs patching. An app is a subscription to its own upkeep whether anyone budgeted for that or not.
- Maintenance nobody owns — a shop paid to ship and leave has no reason to fund maintainability. Whatever gets skipped — tests, documentation, upgrade paths — becomes your cost, discovered later and priced accordingly.
- The rewrite — the most expensive app is the one built cheaply twice. A prototype pressed into production duty accumulates debt until rewriting is cheaper than continuing, and that decision always arrives at the worst possible time.
- The quality you cut in month six — when a fixed-price build runs hot, the pressure lands on the invisible work first: tests, error handling, accessibility. You still pay for all of it — after launch, with interest.
Per-feature quote theatre
The itemised quote — a price beside every feature, a total at the bottom — looks rigorous and is mostly performance. Features do not have independent prices. They share an architecture, a data model and an operational load, and the real cost lives in the interactions between them, which the line items cannot express. Worse, itemised pricing quietly prices the spec instead of the goal: you pay for the feature list you wrote before you knew anything, and every lesson learned during the build becomes a change order. False precision is not honesty. It is a negotiating position formatted as a spreadsheet.
How to get a real number
A real number comes out of a scoped technical conversation, not a form on a website. Put engineers in the room — yours if you have them, the vendor’s tech lead regardless — and make the pricing decisions explicitly: which scope tier, which platforms, which integrations are launch-critical, what compliance actually applies. An estimate produced after those decisions is worth something. An estimate produced before them is marketing.
Our own answer is to make the cost structure boring. A dedicated team is priced as a fixed monthly fee per named engineer — no blended rates, no per-feature theatre, no change-order economy. The only two variables are how many engineers and for how long, and you can see both, adjust both, and stop when the product tells you to. That, plus production code inside the first month, is how a number stays honest after signature.
If you are budgeting an app and want the framework applied to your actual brief, start with our services page and bring the hard questions — the first conversation is a technical call, not a sales call.