Skip to content

About

Why this exists

Most published app development costs are useless. They quote a single average, blend incompatible markets, and give you no way to tell whether the number applies to you. This site tries to do the opposite.

The problem with app cost estimates

"An app" is not a unit of work, which is the reason a published figure for one cannot mean anything. Rather than assert that, here are four builds that all answer honestly to the word:

All four of these are “an app”

6× apart, end to end

Development cost, an internal dashboard

$30K–$43K

1,070 engineering hours · 6 features · 1 surface

$35K$220K

Every one of those four is accurately “an app”, and this model puts 6× between the ends of the row. Published figures run from $10,000 to $500,000 with no indication of what was included, which market the rate came from, or whether infrastructure and maintenance were counted — not because those articles are lying, but because they are averaging across projects that have nothing in common. Note also where this model stops being useful: it will not go below $30K, because a genuinely tiny build is dominated by fixed setup cost rather than by scope. That floor is a limitation, and it is listed as one below.

That is four points chosen to span the range. Here is every combination the site prices, on one axis, with the average marked:

Every combination this site prices

128 builds · same scope, same team, same rates

average $69K
$48K
$90K
Hover a dot to see which build it is.

74 of 128 (58%) land within ±10% of the average. Quote the average to the other 54 and you are wrong by more than that — in both directions, which is why the error does not cancel out.

Three axes, priced separately

What actually decides cost is a specific combination of three independent things: where the software runs, who it serves, and what it does. A booking tool for a clinic and a booking tool for a restaurant look identical on a feature list — one carries HIPAA obligations, audit logging, consent records and an EHR interface, and the other does not.

Change one axis and watch what happens:

One booking tool, two industries

$85K–$115K

2,940 hours · sensitivity 5/5

Compliance applied
HIPAA
Systems to integrate
EHR integration (Epic / Oracle Health)FHIR R4 API layer

$65K–$90K

2,280 hours · sensitivity 2/5

Compliance applied
None applied by default
Systems to integrate
StripeToast / Square / Clover POS

Same platform, same app type, same scope. Healthcare costs 27% more than Food & restaurant — $20K of difference before anyone designs a screen. No single coefficient on a base figure can express that.

Take one base figure and multiply it by two coefficients and you cannot express that difference. So each axis contributes its own engineering hours here and the model composes them. Platform and industry get their own pages and a 128-page combination matrix; app type lives in the calculator, because a three-way matrix would be over a thousand pages nobody could keep honest.

We also keep three things structurally separate that are usually conflated: one-off development cost, recurring cloud and vendor cost, and annual maintenance. Adding them together produces a number that means nothing, so the model never does.

Principles

What we commit to

  • US only, USD only. Every figure is in US dollars for 2026, for software built for the United States market. The hourly rate behind them is our own delivery rate rather than a survey of what the market charges — one rate, no currency selector, and no offshore comparison, because mixing rates in one estimate is how published figures become meaningless.
  • Ranges, not false precision. Every figure is rounded to a step matched to its magnitude and shown with a confidence band. An estimate reading $217,438 is pretending to be a quote.
  • The calculation is yours to inspect. It runs entirely in your browser and your answers are never stored — the estimate itself is released once you give us contact details, and we say so before you answer anything.
  • The model is inspectable. The demonstrations on this page recompute through the same engine the calculator runs — if a rate or a multiplier changes, they move with it. Nothing here is an illustration.
  • The tool argues against us. It will tell you to drop a platform, defer AI, cut integrations or run a pilot — all of which reduce what anyone could charge you.

Where this will be wrong

  • If your requirements are still moving, no calculator can express the real uncertainty. Spend two weeks on a specification first.
  • Genuinely novel technical problems — a new algorithm, unproven hardware, research-stage AI — cannot be estimated from a feature list. Those need a spike, not an estimate.
  • Very small projects are dominated by fixed setup cost, so the model has a floor and will over-estimate a true weekend build.
  • Fixed-price vendors price risk into their number. Time-and-materials for the same scope usually quotes lower and lands higher.
  • We model a competent team executing normally. We cannot model a team that is a bad fit for your problem, which is the largest single source of overrun in real projects.

What is in the model

These were five numbers you had to take on trust. Open any of them and you get the actual registry the engine reads — names, what each one is, and a link where it has a page of its own.

Price your own build.

Every control on one page, a live spec sheet beside it, and nothing behind a form.

Open the calculator