How this estimate is calculated

The estimate is produced by two systems that are not allowed to do each other’s job. A language model reads your description and turns it into a structured specification. Deterministic code reads that specification and computes the number. The model never sees a rate, an hour figure, or a multiplier, and it never returns a dollar amount.

The reason is that language models are good at working out what somebody means and unreliable at arithmetic they have been asked to invent. Ask one what an app costs and you get a plausible figure with nothing behind it. Ask it twice with the same description and you can get two different figures. Splitting the work means the interpretation is as good as a model can make it, and the pricing is repeatable and identical for everyone who describes the same project.

The site also works with no model at all. When no provider key is configured, a local interpreter reads the description instead and everything downstream is unchanged. The estimate gets less perceptive about ambiguous wording and no less rigorous, because the rigor was never in the model.

Exactly one object, validated against a schema before anything is allowed to use it. It holds a short title and a paragraph restating what we think you are building, the kind of application it is, which platforms it targets and whether they are built from one codebase or two, how many distinct kinds of user there are, whether designs and a backend already exist, the expected scale, how clearly the description was written, a yes / no / unknown answer for each of 24 capabilities from user accounts to Bluetooth to offline operation, any compliance regimes, the external systems you named, the assumptions it had to make because you did not say, and the things nobody can know yet.

"Unknown" is a real answer rather than a missing one, and that distinction does more work than it looks like it should. It lets the tool rank which unanswered questions would move the price and ask you about only those. A question about something your project does not do adds no uncertainty, and asking it would burn the two minutes you were willing to spend.

Every project starts with a foundation: the work that exists before a single feature does. Product definition, a design system, navigation, application scaffolding, environments, deployment, a bare API, and store submission. On top of that, each capability the specification says yes to contributes hours to specific workstreams. Bluetooth adds engineering and a great deal of QA and no design at all. An admin portal adds design, its own development, and backend. None of those hours are guessed at the point of use; they are written down, per capability, in one file.

Structural facts then scale those hours. A finished, documented API takes backend and integration work down to 30% of building one from scratch; a partial one to 65%. Finished designs take design work to 35%, and having no brand at all raises it to 130%. Two separate native applications raise application development by 55% against one cross-platform codebase; targeting the browser instead lowers it by 10%. Tablet, watch, and desktop each add their own share on top of design and development.

Two workstreams are derived rather than declared, because that is how they behave. QA runs at 10%–13% of everything there is to test, and project management at 7%–10% of everything above it including QA. Compliance multiplies the result. Then hours become money at a blended rate of $55 an hour, rounded to the nearest $1,000. A figure like $61,847 would imply knowledge nobody has.

Two properties are enforced by tests rather than by good intentions. The breakdown always sums to the headline figure, because every multiplier is applied to line items and never to the total afterward. An estimate whose own arithmetic does not reconcile is worth nothing whatever the number says. And adding scope can never lower the estimate, which sounds obvious and is exactly the kind of thing that stops being true the third time somebody adjusts a multiplier.

Every line item carries a low and a high, and so does the result. A single number would be a lie with a decimal place on it. The low end assumes a clean API, an available client, and no surprises; the high end assumes the ordinary amount of none of those.

How those ranges combine matters more than people expect, and the obvious method is wrong. Adding up every low and every high pits "what if everything went well" against "what if everything went badly," and across thirty line items neither has ever happened. It produces a range three times as wide at the top as at the bottom, which is another way of saying it produces no answer at all.

Real projects overrun in some places and underrun in others. The part of the variance that belongs to a single line item partly cancels out, and is combined in quadrature. The part common to the whole project (the team, your availability, how well the requirements were understood) does not cancel, and is added straight. The share treated as canceling is 60%. That is a judgment rather than a measurement, and it is written down in one place where it can be argued with.

A vague description makes the honest answer less precise, and leaves the project itself exactly as expensive as it was. Conflating those two is how estimating tools end up quietly charging people for not having written a specification yet.

So clarity scales the spread and leaves the midpoint where it was. A clear brief narrows the range to 80% of what the line items already carry; a mixed one leaves it alone; a vague one widens it to 155%. Separately, contingency adds 8% of the midpoint to the top of the range, and each named risk adds a further 3.5% to the top, capped at 15%. To the top only, because contingency describes how projects go wrong and projects do not accidentally finish early.

The confidence level beside the range works the same way and is deliberately pessimistic. It starts high and loses points for how clearly the description was written, for each identified risk, and for each unanswered question that would move the estimate by more than 4%. An estimator reporting high confidence on a two-sentence description is being careless.

Calendar time is more than hours divided by forty. Team capacity scales with the size of the project, because bigger projects run bigger teams; a 1,400-hour project is never one person working for 1,400 hours. Above a ceiling that stops being true and adding people stops adding throughput, which is why the model has one.

Two to three weeks are then added and never compressed: kickoff, your own review cycles, and app store review. And nothing is reported as shipping in under 8 weeks whatever the arithmetic says, because nothing real does.

Not very much yet, and it would be strange to say otherwise on the page that explains the method.

The assumptions are a defensible starting point rather than a price list. They were calibrated so that the three project shapes ANTLR sees most often land where ANTLR quotes them: a focused first version at $15,000–$25,000, a production build at $30,000–$55,000, and a complex one at $55,000–$90,000. That is calibration against experience, which beats nothing and falls well short of calibration against data.

The way to improve it is specific and unglamorous: take ten closed projects, run their real scope through the engine, and compare what comes out against what was quoted and what was spent. Then move the numbers until the engine agrees with history. Until that has happened, this site says "preliminary" everywhere, because that is what this is.

The assumptions in use are version 2026.08-initial. Every figure on this page is read from that file rather than typed here, so this explanation cannot drift away from what the calculator actually does.

It is not a quote and it is not an offer. Nobody has read your requirements, asked the questions a real scoping conversation asks, or committed to anything. What it is good for is finding out early whether the thing in your head is a $20,000 project or an $80,000 one, which is worth knowing before you talk to anybody, including us.

The interpreter can only work with what you give it, and a handful of details move the answer far more than length does.

• Say exactly what backend exists. "We have an API" and "we have a database and an internal tool that reads it" produce very different numbers, and only one of them is the cheap answer.
• Count the kinds of user, not the users. Ten thousand people doing the same job is one role; three people doing three different jobs is three.
• Say whether it has to work without a signal, and what hardware it has to talk to. Either one moves a project up a band on its own.
• Name the systems it has to integrate with. The name matters, because the cost is set by the system on the other side rather than by your app.
• Say whether designs exist, and whether regulated data is involved. Both are large multipliers and both are usually a one-word answer.

Two sentences produces a wide range and an honest one. Two paragraphs produces a narrower range and the same honesty.