Telegram Mini App vs Bot: What to Build for Which Job
Telegram Mini App vs Bot: What to Build for Which Job
Telegram gives you two ways to build something people use inside the app, and teams routinely pick the wrong one — usually the Mini App, usually because it feels more substantial.
The Telegram mini app vs bot decision is not about capability. It is about the shape of the interaction, and most products need one rather than both.
The difference
A bot is a conversation. Messages, buttons, commands. Telegram's API objects still call Mini Apps Web Apps — WebAppInfo, web_app, answerWebAppQuery — so you will meet both names. It lives in a chat and arrives as a notification. Interaction is turn-based: you send something, it replies.
A Mini App is a web application that opens inside Telegram. Your own HTML and JavaScript, rendered in a webview, with access to Telegram's context — who the user is, the current theme, the ability to close and return to the chat.
The practical distinction: a bot pushes, a Mini App is pulled. A bot can message someone tomorrow — once they have started the chat; Telegram's own wording is "Bots can't start conversations with users. A user must either add them to a group or send them a message first." A Mini App only runs while someone has it open, though it can keep state between sessions in CloudStorage, DeviceStorage or SecureStorage, and can sit on the home screen via addToHomeScreen.
That one asymmetry decides most cases.
Build a bot when
The interaction is short. Buy a thing, ask a question, get a link, confirm something. A conversation handles this in fewer taps than any interface you could build.
You need to reach people later. Sequences, reminders, renewal notices, support replies. Only a bot can re-open the conversation, and only with users who have started it or granted write access. A Mini App cannot start a conversation on its own schedule: while it is open it can send data back to its bot (sendData, answerWebAppQuery, shareMessage with a savePreparedInlineMessage id), but it cannot reach a user who does not have it open.
Notifications are the point. Alerts, updates, drip content.
You want zero friction. A bot conversation starts instantly. A Mini App has to load.
You're selling something simple. Stars payments work natively in a bot. Two taps, no card, no page load. For a single digital product that is hard to beat.
Build a Mini App when
The interface genuinely needs to be visual. A catalogue with images and filters, a seat picker, a chart, a map, a game. Expressing these as chat messages is possible and miserable.
There is real state to manipulate. A cart with quantities, a form with dependent fields, a dashboard. Conversations are bad at state a user needs to see and revise.
You are porting an existing web product. If you already have a web app, a Mini App is a distribution channel rather than a rebuild.
Browsing is the activity. Anything where users explore rather than transact.
The comparison
| Bot | Mini App | |
|---|---|---|
| Can message users later | Yes — after Start | Via requestWriteAccess |
| Rich visual interface | Limited | Yes |
| Complex state | Awkward | Yes |
| Time to first interaction | Instant | Load time |
| Build cost | Low | Web app cost |
| Works on any device | Yes | Needs a capable webview |
| Native payments | Yes | Yes |
| Discoverable in chat | Yes | Profile, direct link, or bot button |
Note the last row. Every Mini App belongs to a bot, but it is not only reached through a chat button. Telegram documents "seven different ways of launching Mini Apps: the main Mini App from a profile button, from a keyboard button, from an inline button, from the bot menu button, via inline mode, from a direct link – and even from the attachment menu", plus, since Bot API 10.1 (11 June 2026), launching on a chat join request via sendChatJoinRequestWebApp. A Main Mini App also appears in the Apps tab of search for users who have launched it. So the question is rarely "which one," it is "do I need a Mini App in addition to my bot."
The honest default
Start with a bot. Almost always.
Reasons, in order of how often they turn out to be decisive:
Most products do not need a visual interface. Selling a course, gating a channel, answering support questions, running a funnel — all of these are conversations, and forcing them into a webview adds a load screen and removes the notification.
Push becomes something you have to ask for. This is the big one. A Mini App does not get push for free, but it can request it: requestWriteAccess (Bot API 6.9) shows a native permission popup, and if the user accepts you get a WriteAccessAllowed service message and allows_write_to_pm on the user, after which the bot behind the Mini App can message them. The real cost of Mini App-first is that push turns into an opt-in prompt you have to earn rather than a side effect of pressing Start.
Bots are dramatically cheaper. A Mini App is a web application with all the associated cost — frontend, hosting, state, browser compatibility, design.
You can add a Mini App later. A button in your bot that opens one is a small change. Going the other way — bolting conversational reach onto a Mini App-only product — means building the bot you skipped.
When both is right
Larger products often need both, with a clear division:
- Bot: notifications, sequences, support, payments, anything time-based
- Mini App: browsing, configuration, dashboards, anything visual
A store is the clearest example: the Mini App is the catalogue, the bot handles order confirmations, delivery and support. Each does what it is good at.
The failure mode is duplicating functionality across both. Pick one home for each job.
The question to ask
Does the user need to look at something, or do something?
Look at — a catalogue, a chart, a seat map — that is a Mini App.
Do — buy, ask, confirm, subscribe, get told — that is a bot, and it will be faster to build and better to use.
When it is genuinely ambiguous, build the bot. It is cheaper, it keeps the ability to reach people, and it is the foundation the Mini App would sit on anyway.
Based on Telegram platform capabilities as of September 2026. Mini App APIs evolve; check the official documentation before building.