How the estimates work

Two dollar figures, and they mean different things.

Usage value is what the units you burn are worth. Take the units, multiply by the tool’s own price per unit. Nobody invoices you for it. It is simply the fair way to compare how efficiently two tools do the same job.

Plan spend is the money that actually leaves your account: whole months of a real plan, because that is how subscriptions work. Go one credit past a month’s allowance and you buy another whole month. So plan spend jumps in steps while usage value slides smoothly. Plan spend is the number you pay, and the number the cheapest pick is ranked on.

Claude Code is the one row where that months figure rests on an estimate rather than a published quota — see the note under the conversion table — so its plan spend inherits that uncertainty along with everything else.

The iteration tax is the honest part. Base costs assume the platform understood you the first time, which it did not. Your prompting style sets the multiplier: careful prompter ×1.2, normal human ×2.5, heavy iterator ×5, vibes only ×8.

The 40% debug surcharge sits on top of that, and it is not the same thing. Iteration is you changing your mind. Debugging is the app being broken in a way neither of you intended.

Unlike the plan prices and allowances above, that 40% is an assumption, not a measurement. No vendor publishes a debugging figure and we have not yet measured one, so it is a single flat rate applied to every platform equally — it does not claim that debugging costs the same on a visual builder as it does on a coding agent. It is the largest un-sourced number on this site, it compounds with the iteration multiplier, and real-build submissions are how it stops being a guess.

Platform docs. Plan prices, included allowances and what counts as a credit or a token all come from each platform’s own published pricing. We re-check them on the last-checked date printed on every estimate and pricing guide.

Community build reports. Feature-level costs are seeded from what builders publicly report spending — forum posts, threads, and post-mortems where people share the actual credit or token counts for a working feature. These are noisy, which is why we publish ranges.

Real-build submissions. The long game: receipts sent in by people who finished something. As those accumulate, they replace the estimates rather than decorate them. Submit yours →

When a number changes, the change gets written down rather than quietly swapped in. See the pricing changelog →

A point estimate would be more satisfying and less true. The same feature, on the same platform, on the same day, can cost twice as much depending on how big your project already is, how the model decides to approach it, and how many times you say “actually, no.”

So every line item is a range, and ranges add up into ranges. If your build lands inside the published range, the estimate did its job. If it lands outside it, we want to know — that is what the real-builds page is for.

Two things get confused here, so to be explicit: published ranges reflect build uncertainty; on top of that, every receipt itemizes a 40% debugging contingency — they are different things. The contingency is a line in the arithmetic, added before the range is drawn. The range is how wide we think the answer could still be afterwards.

One consequence worth stating plainly: these are estimates for budgeting, not quotes. Nobody here can promise what a platform will charge you, and any site that does is guessing with more confidence than evidence.

The calculator has an optional first step: describe your app in a sentence or two and it fills in the type and the features for you. Your description goes to an AI model, which picks the closest of the 12 app types, the features it implies, and a colour-coded verdict on whether AI app builders are the right tool for the job at all.

The arithmetic stays deterministic. The AI never touches a number. All it does is fill in the same two dropdowns you could fill in yourself; everything after that is the formula above, run over the same data, with the same result you would get by clicking the buttons by hand. Skip the box entirely and the receipt is identical.

A red verdict is not “impossible”. It means this kind of app fights these tools — live multiplayer, medical records and other regulated data, training your own AI model, physical devices, a real iPhone or Android app. People ship those things every day. They ship them writing real code, mostly outside the builder, and at that point the receipt stops describing their project. Yellow means buildable with caveats, and the caveats are printed on the receipt rather than implied.

Descriptions are stored under a one-way fingerprint of the words, so the same idea asked twice costs one call and gives the same verdict. Nothing about who asked is kept: no accounts, no cookies, and the five-per-hour limit runs off a scrambled daily counter, never your address.

This site earns nothing today — the links to the platforms above are plain links. If we ever run affiliate links, they will be disclosed on the page that carries them.

It would not touch the ranking. The cheapest platform on any receipt comes out of the same estimator maths, ranked on plan spend — the same sums on every page, over the same data — and nothing in those sums knows which links pay. If the cheapest option pays us nothing, it still gets the scissors icon.

Where we are unsure, the page says so. Where a number is coarse, it is marked coarse rather than rounded into a false decimal. And when a platform changes its pricing, the fix is a dated changelog entry, not a silent edit.