Telegram Mini App or a website: choosing the format without overpaying

A client arrives saying they need a Telegram Mini App, and the first question we ask sounds blunt. Where do the first hundred people come from? With an answer in hand we talk about scope and timelines. Without one the format will not save the project, because a mini app removes the steps before the first action and creates no flow of people on its own.

What it is once you drop the marketing

A web application that opens inside the messenger. The user installs nothing and registers nowhere, since opening it from a chat already identifies them. Technically it is a normal frontend plus a platform SDK giving identity, payments and a notification channel through a bot. After that your own logic starts. It differs from ordinary web development in two ways only: the screen is narrow, and the person arrived from a conversation.

The format fits when the path is short and people are nearby

First condition, the audience already lives 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. Second condition, a short path: pick, add to cart, pay, book a slot. The shorter the road, the better this format performs. A ten screen journey falls apart here faster than on a website, because the person came from a chat and still holds a conversation in their head.

Third, speed of changes matters. No app stores, no release review. A fix reaches users the same day. For a product you are still tuning, that is sometimes the deciding argument.

Where the format loses

Search traffic. Crawlers do not see inside a mini app, so organic discovery will never come from it. If search is your main channel, the website stays your main asset. Offline work and heavy device operations are out too: capture, file processing and background tasks live more reliably in a native app. And the most common case of all. If there is no audience in the messenger, the format does not help at all, because you need an acquisition channel first, otherwise you end up with a working product nobody opens.

What you give up with each option

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

The table does not answer which option is better. It shows what each choice costs you. For a mini app the price is search traffic and offline.

What we built in this format

MOST. is a single storefront engine for Telegram and MAX. 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 sync among the integrations.

The practical lesson from that work is worth more than the stack. The engineering part of launching a second storefront really is short, and the content part is not. Catalogue, photography, descriptions, payment setup and training the client’s staff take longer than assembling the storefront itself. When a vendor promises a store in a few days, they are counting their own half of the work, which is not dishonest, it simply leaves the other half with you.

A second example from a different domain. For Gazprombank.Tech we built a financial literacy game inside the bank’s mobile app, where content is served from the backend and the client only renders it, so questions update without shipping a release. The same principle applies to mini apps and matters more than the framework choice, because separating content from the shell decides whether you can change the product after launch without a developer.

How to test the decision before building

Count where the first hundred users come from. Not a thousand. A hundred.

An answer like «from our channel, it has four thousand subscribers and we have seen them click links in posts» means 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, you simply hit the same budget sooner. People often object that all their clients are in Telegram anyway. That is easy to check: look at how many wrote to you in the messenger last month instead of calling or coming through the website.

What I do not know about this format

We have no data on how mini apps hold retention over a long distance. We have seen launches and first weeks. Watching the same storefront run for half a year has never happened to us, so about the long life of the format I can say nothing.

Back to the question from the opening. It sounds rude. It saves weeks. Selling a mini app to a client who cannot name the source of their first hundred users is pointless, even when they are willing to pay for it. If you do have that answer, tell us where those people come from and we will say whether you need this format at all.