maxмини аппмакс

Mini App in MAX: when a bot is not enough - device, cases, deadlines

September 15, 2026
Mini App in MAX: when a bot is not enough - device, cases, deadlines

The bot does a great job as long as the script fits into the dialogue. Answering a question, accepting an application, sending an order status is a correspondence, and correspondence is enough for it.

The problem begins where the choice appears in the scenario. A tariff with parameters, a catalog of thirty items, a form with six fields, a constructor where one item depends on another. All this can be crammed into buttons and text messages, but the result will be an interface from 2010 - the user scrolls through the steps back and forth, gets confused, and quits in the middle. This is where the bot stops coping and the Mini App comes into play.

What is it technically

Mini App in MAX is a web application that lives inside the messenger and is opened by a button from the bot. The technologies under the hood are ordinary: HTML, CSS, JS, any framework that can be assembled into static form. We are building the front end using React and Next.js - MAX doesn’t require anything specific, it’s the same build as for a regular website, just with a different entry point.

The launch scheme is simple: the application is assembled, uploaded to hosting with https, and its URL is linked to the bot through the affiliate panel. From the MAX server it sends a bridge - MAX Bridge - through which the application communicates with the platform: receives user data, calls native interface elements, exchanges events with the bot.

An important point that is missed in half of the articles on this topic: hosting must be fast and stable. The mini-application opens in the messenger, the user does not have the patience to wait five seconds for the first rendering - he will simply close the tab and return to correspondence with the bot. Free static hosting with a cold start is not suitable here; This is why we deploy it on our servers.

Where Mini App is really needed

Not everywhere where it is possible, it is necessary.

Constructor with parameters. Tariff, where the user selects a term, volume, a set of options, and all this changes the final price in real time. In correspondence with a bot, this means five messages in a row and the constant “can you go back a step?” The interface has one screen with sliders and switches, and the price is immediately visible.

Catalogue. More than ten positions with filters, categories, search - this is no longer a list of buttons, but a showcase. Cards, grids, sorting work here - everything that correspondence physically cannot show.

Personal account. Order history, subscription status, settings, referral program - data that the user wants to see in its entirety, and not fish out with commands for one item.

Payment with details. If it’s just “pay 500” rubles" - the payment button in the chat will suffice. If you need to choose a method, enter a promotional code, look at the breakdown - this is already a form, and the form lives in the interface, not in the dialogue.

Game mechanics - sweepstakes, a wheel of prizes, accumulative points - also almost always go to the Mini App: animation and interactivity in correspondence do not work in principle, and on the web it takes several days of layout. development.

If the whole scenario is “answer a question” or “take one parameter and confirm”, the widget is a waste of budget. A FAQ bot, registering for a procedure in one service, accepting an application with three fields - all this is closed with a dialogue for less money and without a separate front-end, which then needs to be supported.

A good rule: if you can draw a scenario as a flowchart with forks of two or three options at each step, a bot is enough. If there are more forks or you need a visual choice from many options at the same time, it’s time to go to the interface.

What a good Mini App looks like in MAX

This is not the technical part, but the design part, and this is exactly where they most often save in vain.

The mini-application opens inside the messenger, and the user expects it to look like a native part of the platform - not like a built-in website with a foreign font and the wrong rounding radius. In practice, this means: cards with a large radius, compact touch targets for the finger rather than the cursor, predictable navigation without deep nesting of screens, and a tab bar or back button that behaves the same as in the rest of the messenger.

When we design such interfaces - be it a tariff constructor with a choice of parameters and live price recalculation, a catalog with a purchase without unnecessary authorization, or personal account with history and referral - there is one rule: first the mobile screen, then stretching it to the desktop, if it is needed at all. Widgets are opened 95% of the time from a phone, and the “wide screen, then shrink” design usually looks cramped and illogical in the messenger.

Limitations to be aware of in advance

MAX makes sure that the mini-app does not mislead the user about what it does - the same requirement as for bots. The name, icon and first screen must correspond to the actual function.

Mini App development usually costs less than a separate mobile application - not significantly, but noticeably, because native iOS/Android builds, publication in stores and their separate support are not needed. But this does not mean “cheap at all” - the design of an interface with several screens and logic still requires time comparable to a small landing page, only with more attention to interactive states: what happens when loading, when there is an error, when the list is empty.

Timing

A simple Mini App for 3-4 screens without complex logic - one and a half to two weeks, including design and layout. A constructor with several dependent parameters, a personal account with a history and a referral - from three weeks, and this is without a guarantee that the technical specifications will not grow in the process: such interfaces almost always have “let’s add a screen with...” after the start.

Allow a separate week for testing on real devices - the layout of mini-applications is capricious for different versions of MAX and different screens, and what looks beautiful in the design sometimes rides on a specific phone.


We design mini-applications for MAX and Telegram - from the tariff designer to a personal account with a referral. If you are in doubt whether you need a bot or a full-fledged interface, write and let’s look at the scenario together .

Илья Васильев
Илья Васильев
Founder, Vasilyev Design