Telegram Mini App or a website: choosing the format without overpaying
Choosing between a mini app, a website and a mobile app is almost never a technology decision. It is a decision about where people come from and how long a path they will tolerate.
Below are the signals that settle it in one conversation.
What a mini app actually is
A web application that opens inside the messenger. Users install nothing and register nowhere: they are already identified by the fact that they opened it from a chat.
Technically it is a normal frontend plus a platform SDK that provides user identity, payments and a notification channel through a bot. Which gives the format its defining property: it removes the steps before the first action, and it does not create traffic.
When the format fits
Signal one: the audience is already in the messenger. A channel, a client chat, a base of conversations. The mini app converts an existing contact into an order, and that is its strength.
Signal two: the flow is short. Pick, add to cart, pay. Book a slot. Renew a subscription. The shorter the path, the better this format performs.
Signal three: release speed matters. No app stores and no review queues, so a fix reaches users the same day.
When it does not fit
You need search traffic. Crawlers do not see inside a mini app. If you count on organic discovery, the website remains the main asset.
You need offline work and heavy device features. Capture, file processing and background tasks live more reliably in a native app.
There is no audience in the messenger yet. The format does not help here: without an acquisition channel you end up with a working product and no users.
Comparison by the deciding factors
| Factor | Mini App | Website | Mobile app |
|---|---|---|---|
| Barrier before first action | minimal | medium | high, install required |
| Search traffic | none | yes | none |
| Offline | no | partial | yes |
| Release speed | immediate | immediate | store review |
| Entry budget | from 150,000 roubles | from 50,000 roubles | from 500,000 roubles |
The table does not answer «which is better». It answers «what you give up by choosing this». For a mini app the two losses are search traffic and offline.
What we built in this format
MOST. is a single storefront engine for messenger commerce: catalogue, cart, checkout, payments, promo codes and order statuses live in one codebase while the styling changes per brand. Laravel and Filament on the backend, React and TypeScript on the frontend, card acquiring and accounting system sync among the integrations.
The practical lesson from that work is worth more than the stack. The engineering part of launching a second store really is short. The content part is not: catalogue, photography, descriptions, payment setup and training the client’s staff take longer than assembling the storefront. When a vendor promises «a store in a few days», they are counting their own part only.
A second example from a different domain. For Gazprombank.Tech we built a financial literacy game embedded into the bank’s mobile app, where content is served from the backend and the client only renders it, so questions can be updated without shipping a release. The same principle applies to mini apps and matters more than the framework choice: separating content from the shell decides whether you can change the product after launch without a developer.
How to test the decision before building
The cheapest way to validate the format is to count where the first hundred users come from. Not a thousand, a hundred. If the answer sounds like «from our channel, it has four thousand subscribers and we have already seen them click links in posts», the format fits. If the answer starts with «we will run ads», calculate the cost of acquisition first: with expensive traffic, saving on development changes nothing.
FAQ
Is a Telegram Mini App indexed by search engines
No. The content inside a mini app is not reachable by crawlers, so it brings no organic traffic. If search is your main channel, the website stays primary and the mini app becomes an additional flow.
Can one codebase serve several messenger platforms
Yes for the shared logic and interface. Authentication, payments and the platform SDK differ, so a second platform is cheaper than the first but not free, and only if that separation is designed in from the start.
Is a mini app cheaper than a mobile app
Usually yes, and faster: no app stores, no review queues, updates ship immediately. The trade off is that complex offline scenarios cannot be built this way.