How the estimates work

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, and it lands on every project regardless of how carefully you prompt.

Platform docs. Plan prices, included allowances and unit definitions come from each platform’s own published pricing, re-checked on the lastVerified 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, ranges add up into ranges, and the total carries a ±40% band on top. If your build lands inside that band, the estimate did its job. If it lands outside it, we want to know — that is what the real-builds page is for.

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. That description is sent to Claude, 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 it at all.

The arithmetic stays deterministic. The model 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 chips by hand. Skip the box entirely and the receipt is identical.

A red verdict is not “impossible”. It means this app class fights these tools — realtime multiplayer, regulated medical data, custom model training, hardware, genuinely native mobile. People ship those things every day. They ship them writing real code, mostly outside the builder, and the estimate on the receipt stops describing their project. Yellow means buildable with caveats, and the caveats are printed on the receipt rather than implied.

Descriptions are cached by a hash of their content, so the same idea asked twice costs one call and returns the same verdict. Nothing about who asked is stored: no accounts, no cookies, and the per-visitor rate limit keys off a salted hash of the IP rather than the address itself.

This site carries affiliate links. Some of the platforms above pay a commission if you sign up through them. That pays for the domain and the time spent re-checking prices.

It does not touch the ranking. The cheapest platform on any receipt is computed by estimate() — the same function on every page, run over the same data — and nothing in that function 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.