A bot and a Mini App solve the problem differently
A bot talks in messages. Every step is a separate message with buttons underneath, and the chat history keeps growing downwards. The user moves in a straight line: answer a question, get the next one.
A Mini App is a web app that opens inside Telegram when you tap a button. Full screen, with its own lists, filters, cart, swipes. Technically it's an ordinary frontend, usually React, it just lives in a messenger window instead of a browser.
The main difference isn't looks, it's the number of actions. In a bot, changing one detail of an order often means walking the whole chain again or scrolling up through the chat hunting for the right message. In a Mini App the user sees the entire order on one screen and edits the line that's wrong. The more choices your process contains, the more every step backwards costs you in a bot.
When a plain bot is enough and you shouldn't pay for a Mini App
Straight answer: in about half the enquiries that reach us with the words "we need a mini app", a bot does the job, and it's cheaper to build and cheaper to maintain.
A bot wins when the scenario is short and linear and the choice fits into a few buttons. A three or four field enquiry form, booking for a single service, notifications, an internal tool for staff - none of that needs an interface.
A word on internal tools. If five people on your team use it, they don't need a pretty interface, they need speed. A command-driven bot is genuinely more convenient than an app here.
- an enquiry form with three or four questions plus a notification to a manager;
- alerts: new order, payment received, enquiry sitting unanswered;
- answers to common questions and documents delivered at the tap of a button;
- internal tools: team report, stock status, quickly flagging a deal;
- a one-off promo or quiz that runs for two weeks and then shuts down.
Where a bot starts costing you sales
The point where we almost always recommend a Mini App is when a catalogue appears. With ten items, buttons work fine. With a hundred, people scroll through messages, lose their place and leave.
The second marker is a cart and repeat orders. In a bot you have to show the cart state as its own message and update it on every change, otherwise outdated versions with a different total stay sitting in the chat. The customer sees three different totals and can't tell which one is real.
Third is any choice from a grid: date and time, a seat in a venue, size and colour, a price filter. You can't show a grid properly with buttons, so you end up paging through five options at a time.
And fourth is the account area. Order history, delivery status, loyalty points, subscription, contracts. That's a set of screens, not a set of messages.
What building a Telegram Mini App actually involves
A Mini App doesn't replace the bot, it lives inside it. The bot stays as the entry point and the notification channel, and the app opens from a menu button or from a message. So the bot will be in the quote either way, even if the whole interface moves into the app.
Then comes the part worth asking a contractor about. When Telegram opens your app, it passes user data into it - initData. That data is signed, and the signature has to be verified on the server using the bot's secret key. If there's no check and the backend simply trusts whatever the client sends, anyone can substitute someone else's ID and open someone else's account area. This isn't theoretical. It's the first thing we look at when we're asked to pick up somebody else's app.
Three more things move the quote more than design does. Payments: through Telegram's built-in payments or through your own acquiring, with different requirements and different amounts of work. Data: the app needs a backend and a database, it can't just live "inside Telegram". And theming: Telegram passes the user's theme colours, and the app has to look right in both light and dark.
Mistakes you can spot on the first screen
The most common one: the app was built like a regular mobile site and dropped into the messenger window. It reads as a foreign insert, and users feel it.
Your own logo and name at the top. Screen space is tight and Telegram already has a window header. You get two headers in a row and less room for the product.
Your own back button in the top left corner. It fights with the system one, and people exit twice from something they meant to exit once.
Hard-coded colours instead of theme colours. The customer is on dark mode, you've got a white background with grey text, and it barely reads.
No loading states. Messengers get opened on the underground and on bad Wi-Fi. If the screen is blank and nothing seems to be happening while a request runs, people assume the app is broken and close it.
And on asking for an SMS code again. If the user already arrived from Telegram, making them enter a code is an extra step, and that's where they drop off.
A sensible order: bot first, app later
If you don't yet know whether customers will show up in Telegram, starting with a full app is expensive. We usually suggest building a bot that covers the core scenario, then spending a month or two looking at the numbers: how many people reached the enquiry stage and where exactly they dropped out.
That data pays for the design work later. You come to design knowing that 80 percent of requests fall into three product categories and that nobody touched the brand filter at all, instead of guessing.
The reverse happens too. If you already run a working online store with a clear product range, an intermediate bot step is pointless and the app gets built straight away.
What makes up the quote
Our site publishes a starting price for each service - Telegram bots, web services, online stores. That's a floor, not a price for any project: the real figure appears after a brief, once the list of screens and integrations is clear.
The same handful of things push the price up. The number of screens and distinct states. An admin panel where you change products and prices yourself. Payments and refunds. Integration with a CRM, a warehouse system or accounting software, where the bulk of the effort is almost never in the app itself but in wiring up to someone else's system. And a separate web version outside Telegram, if you need one.
Ask for the quote as a list of blocks with hours or amounts attached. If you get a single line with a number, that's not a quote, it's a number: you can't tell what to cut when the budget doesn't add up.
Acceptance: twenty minutes with your own hands
Don't sign off on work from a screen recording made on the developer's machine. Open the app on your own phone and walk the whole customer path through to payment.
What to check:
- switch your phone to dark mode and reopen the app - background and text should still be readable;
- test on iPhone and on Android, then in the Telegram desktop app, where the window size is different;
- put the phone on a throttled connection and see what appears instead of a blank screen;
- hit the system back button halfway through an order and see where it dumps you;
- close the app and open it again - the cart and anything you typed should still be there;
- make a test payment and cancel it, then check the order isn't stuck in a "paid" state;
- confirm that after an order the bot notifies both you and the customer;
- try opening someone else's order by swapping an ID in the link or the parameters, if that's even possible.
Choosing between a bot and an app comes down to one question: how many choices your customer makes on the way to an order. One or two, and a bot is enough. A catalogue, a cart, a grid of time slots, an account area, and you need an interface - at which point what matters isn't design but signature verification on the server and how the app behaves on a bad connection. At EFIMOV DEV we build both: the site lists starting prices for bots and web services, and we put together an itemised quote after a brief, where the first thing we look at is whether a cheaper option would do.
Frequently asked
Does a Mini App replace a website?
No, and you shouldn't plan on it. An app inside Telegram is only reachable by people who have the messenger and have already found your bot. It isn't indexed by search engines, and a link from an ad can't be opened in a browser. If you need traffic from search, the site stays, and the app works as a convenient channel for people who have already arrived.
Can an existing bot be converted into a Mini App?
Partly. The server logic, database and integrations are usually reused, which saves a noticeable share of the budget. The interface has to be built from scratch: buttons under messages don't turn into screens by themselves.
Do I need an admin panel?
If you change products, prices or schedules more than once a month, yes, otherwise every edit goes through the contractor and onto the support bill. If your range is stable and edits are rare, you can launch without one and add it later.
What about customer data security?
Ask the contractor directly: where the database sits, whether the initData signature is verified on the server, and who has access to the admin panel. If the answer to the first is "on a server" and the answer to the second is "Telegram is secure anyway", that's a reason to be wary.
Will the app work if the customer has an old phone?
Usually yes, but it needs testing on real devices. Heavy animation and large images lag far more on older Android phones than on a developer's test emulator.