Calculator
Estimate a build, in delivery days
Pick a bot type and the things it must do, and the calculator returns the effort in delivery days, broken into named line items, with the calendar time that implies. It also states the hard constraints your configuration runs into, which is the part a number on its own cannot tell you.
How this calculator works
- Runs without JavaScript
- The model, the FAQ and the breakdown are server-rendered
- Shared model
- The same estimate() the Worker and the unit tests call — the browser cannot drift from the quote
- Bundle size
- Under 12 kb gzip, enforced per entry point at build time
As of 2025-10-01, Telegram Bot API 13.4
The breakdown appears here once the arithmetic runs. With JavaScript disabled it will not, and the written breakdowns cover the same model.
| Work | Days | What it covers |
|---|
A one-page PDF: what is in scope, what is explicitly not, and the assumptions behind the estimate. It is a draft for discussion, not a quotation.
What this is, and what it is not
This calculator returns days rather than a headline price, for the same reason the pricing pages do: days are arguable. If it tells you a bidirectional CRM integration is four days and you think that is high, you can say so and there is a conversation to have. A figure with no working shown gives you nothing to push against, which is usually the point of publishing one.
The model behind it is the same one the catalogue is built from. Each bot type carries a base row — the conversation and business logic, the integrations it inherently contains, and the failure handling that separates a product from a demo — and every option you add is priced against that base. Choosing Stars on a bot that already contains a Stars checkout adds nothing, because you are not buying it twice.
What it is not is a quote. A quote is fixed against a written scope after a conversation, and once fixed it does not move because the work turned out harder than we estimated. What this gives you is an honest order of magnitude and, more usefully, a breakdown you can take to anybody else and compare on the substance rather than on the total.
The most valuable output is often the warnings rather than the number. Configure a crypto product with a card gateway and it will tell you that UAE acquirers do not underwrite virtual asset businesses — which means the number above it is a price for a project that cannot happen as configured. Those rules decide more GCC projects than architecture does, and they are cheaper to learn here than after a merchant application is refused.
How it counts
Effort days and calendar days are different numbers, and the calculator shows both.
Delivery is planned at roughly sixty per cent utilisation on any one project, so ten effort days is about seventeen calendar days. Quoting effort as calendar time is the most common way a fixed date is missed.
Nothing is charged twice for a capability the base build already contains.
The storefront is a Mini App by definition and the assistant is the retrieval product. Selecting those options on those bot types changes nothing, and the breakdown shows why rather than silently absorbing it.
Additional integrations are priced by depth, not by count alone.
Read-only is cheapest because nothing has to be reconciled. Bidirectional costs most because two systems that both write can disagree, and deciding who wins is a conversation before it is code.
Arabic costs more than Russian as an additional language.
The difference is direction rather than words: mirrored layouts, direction marks on mixed strings, and inline keyboard labels rewritten to fit a narrower space. Translation is the cheapest part of adding a language.
Money appears only when the day rate has been signed off.
Effort is an engineering estimate and ours to publish. A price is a commercial commitment, and the calculator will show days with no money column rather than invent one.
The estimate excludes third-party costs entirely.
Gateway fees, CRM seats, model usage and KYC verifications are billed by those providers on your own contracts. They belong in the running cost rather than in the build, and the pricing pages cover them.
Questions about the estimate
Is the number this produces a quote?
No. It is an estimate from a public model, and it does not know anything specific about your situation. A quote is fixed against a written scope after a conversation, and it is the fixed one that binds us — this one binds nobody, which is why the working is shown.
Why does adding an option sometimes change nothing?
Because the base build already contains it. A Stars checkout on the Stars payments bot, a Mini App on the TON storefront, retrieval on the assistant — those are the product rather than an addition, and charging for them again would be double counting.
How accurate is it?
Accurate enough to plan a budget and to tell whether a conversation is worth having. It is derived from the same day counts the catalogue prices come from, so it is consistent with everything else on this site. What it cannot see is the specific awkwardness of your existing systems, which is where estimates usually move.
What are the warnings underneath the estimate?
Hard constraints your configuration runs into — platform policy, acquirer eligibility, indexing behaviour. They are not sales objections and several of them will tell you a configuration is impossible rather than expensive. Those are the ones worth reading first.
Does it work without JavaScript?
The page and its explanation do; the calculation does not, because arithmetic has to run somewhere. If you have JavaScript disabled, the pricing breakdowns cover the same model in prose, and the bot will answer a configuration question directly.
Does using it send you my configuration?
Only if you press the button that says so. The calculation runs entirely in your browser, and nothing is transmitted until you choose to send it, at which point it goes to the bot as the starting point of a conversation.
Why can I not enter my own day rate?
Because the output is meant to be comparable with the rest of this site rather than configurable into whatever number you were hoping for. If you want to apply a different rate, the day counts are right there and the arithmetic is one multiplication.
Related reading
For the same model explained line by line rather than computed, see the cost breakdowns.
To understand what each line item in the estimate actually covers, read the full build breakdown.
For fixed prices and delivery dates against each bot type, see the priced catalogue.
If the estimate suggests the answer is not to build at all, start with the comparison pages.
For why no case-study metric appears anywhere on this site, read the evidence policy.