Cost

What the smallest viable bot costs

A defensible MVP is five to eight delivery days: one flow, one integration, real failure handling, and enough instrumentation to learn something. Below that you are buying a demonstration. The corners worth cutting are features; the corner never worth cutting is knowing when it breaks.

What the smallest viable bot costs: effort, cost and what moves it

Fixed price: $2,940 USD
Delivery: Awaiting sign-off

Effort: 7 delivery days
Biggest cost driver: The cut list — deciding what not to build
Commercial basis: Fixed price agreed before work starts; scope changes quoted separately
Year one, beyond the build: Support retainer, Managed hosting, plus third-party trial tiers

As of 2025-10-01, Telegram Bot API 13.4

Why this costs what it costs

The word MVP is used for two different things, and the confusion is expensive. One is a first version of a product that real customers use, which must therefore actually work. The other is a prototype that proves a concept to a stakeholder, which need not. Both are legitimate purchases and they have different prices, so the first thing worth settling is which one you are buying.

For the version real customers touch, the useful discipline is cutting scope rather than cutting quality. One flow instead of five. One integration instead of three. No admin dashboard — your team can use the Telegram side. No analytics beyond counting what happened. What stays in regardless is validation, idempotency and an alert when something fails, because those are what make the difference between learning that your idea did not work and learning that your bot did not work. Those two lessons cost the same to obtain and only one of them is useful.

The second discipline is building the first version so the second one is an extension rather than a rewrite. That mostly means separating the conversation layer from the business logic, keeping state somewhere durable from the start, and not hard-coding the single integration into the flow. It costs perhaps half a day at MVP scale and it is the difference between a second phase that adds features and a second phase that starts again. We have inherited enough thrown-away first versions to price that half-day as the bargain it is.

What an MVP genuinely should not carry: multiple languages, a Mini App, payments, or a reporting surface. Each of those is a real slice of work and none of them tests whether anyone wants the thing. If your hypothesis requires payments to be true, then payments are in scope and this is not an MVP — it is a small product, priced on the payment page.

The breakdown

Work	Days	Cost	What it covers
Hypothesis and cut list	0.5	$210	What this version is meant to prove, and the explicit written list of what is deliberately absent. The cut list is the deliverable that keeps scope from returning.
Single flow build	2	$840	One conversation, done properly: commands, state, validation, and the messages for the paths where the user does something unexpected.
One integration	2	$840	The single external system the hypothesis needs, with boundary validation and queued writes so an outage delays rather than loses.
Minimum failure handling	1	$420	Idempotency, retry tolerance and an alert that reaches a person. The line that keeps a failed experiment from being mistaken for a failed idea.
Learning instrumentation	0.5	$210	Counting what actually happens: starts, completions, drop-off point. Without it the experiment produces an opinion rather than a result.
Deployment	1	$420	Webhook registration, secrets, monitoring and a handover short enough to fit in one session, because at this size ceremony costs more than it returns.
Total	7	$2,940	Fixed on signature. Scope changes are quoted separately, never absorbed silently.

What moves the number

A prototype for a stakeholder and a first version for customers are different products.

A demonstration needs no failure handling and no durable state, and is genuinely cheaper. Deciding which one you are buying before quoting is the difference between a fair price and an argument.

Separating conversation from business logic costs about half a day at this scale.

It is what makes version two an extension rather than a rewrite. Skipping it saves half a day now and costs several later, which is the worst trade available in this category.

Payments cannot be cut if the hypothesis is about willingness to pay.

A bot that collects interest is not evidence of revenue. If the question is whether people will pay, payments are in scope and this stops being an MVP by day count.

Instrumentation is cheap before launch and impossible afterwards.

Data about the two weeks you did not measure does not exist. Half a day at the start is what makes the experiment answerable at all.

A second language doubles the copy surface without testing the hypothesis.

Launch in one language and add the second once the idea is proven. This is the most common scope addition at MVP stage and the least defensible.

What year one actually costs

Running cost	Year one	Detail
Support retainer	$3,480/yr	Optional at this stage and reasonably declined for a short experiment. Worth adding the moment the MVP survives its first month and starts being depended on.
Managed hosting	$660/yr	Still recommended, because an MVP that dies quietly teaches you nothing about your hypothesis and everything about your hosting.
Third-party trial tiers	billed by the provider	Most integrations have a free or trial tier adequate for an experiment. Check the limits before launch — hitting one mid-test invalidates the result.

Buying the same thing elsewhere

Where you buy it	What the money buys	What you carry
A no-code builder	A working flow this week for a monthly subscription, with no engineering. For testing whether anyone engages at all, this is frequently the correct first purchase and costs a fraction of a build.	You cannot test anything requiring computation against live data, and nothing you build is portable to version two. Excellent as an experiment, worthless as a foundation.
A weekend build by someone internal	Effectively free, fast, and it stays in the building. Perfectly reasonable when someone technical is genuinely enthusiastic about the idea.	It becomes production by accident, with no failure handling and one person who understands it. Most bot rescues we are asked to price started exactly this way.
A full first version	Everything the product should eventually do, built once, with no throwaway work and no second engagement.	You spend the full budget before learning whether anyone wants it. Right when the demand is proven and the requirements are known; wrong when either is a guess.

Questions about the money

What is the smallest thing you will build?

Around five delivery days. Below that the scoping, deployment and handover overhead exceeds the engineering, and you are paying us to do process. If your idea genuinely fits in less, a no-code builder or a capable freelancer serves you better and we will say so.

Can we upgrade the MVP later, or is it throwaway?

It is built to be extended — durable state, separated logic, and the integration behind an interface. That is a deliberate half-day at this scale. What is genuinely absent is features, not foundations.

What do you cut first?

The admin dashboard, the second flow, the second language, and any reporting beyond raw counts. What never gets cut is validation, idempotency and alerting, because those are what let you distinguish a failed idea from a failed deployment.

How long until we know if it worked?

That depends on your traffic, not on the build. What we can guarantee is that the instrumentation will answer the question when the traffic arrives, which is the part that is usually missing.

Should we just use a no-code builder instead?

Often, yes, and that is an honest recommendation rather than a hedge. If the hypothesis is whether people will engage with a conversational flow, a builder tests it for a fraction of this and in days. Come back when you need computation against live data.

What if it works and we need to scale quickly?

The architecture handles considerably more load than an MVP will see, because the runtime scales horizontally by default. What needs revisiting at scale is rate limiting, queueing for broadcasts and the admin surface — all additive rather than a rebuild.