Telegram bot and Mini App development

The difference is structural, not cosmetic. A bot is a conversation: commands, buttons, states. It is cheap, quick to ship, works on any handset and asks nothing of the customer beyond the Telegram they already have. A Mini App is a full web application living inside the messenger — its own interface, a catalogue with filters, a basket, a map, a personal account — opening instantly, with no install and no trip to an outside website.

The rule we apply in the first meeting: if the whole journey fits into seven to ten screens of buttons, build a bot. If it needs catalogue filters, a booking calendar, a map or a long form, build a Mini App. Most often the answer is both — the bot handles sign-in, notifications and reminders, the Mini App handles the shopfront and the payment.

• Shop: catalogue, basket, payment, order status, courier notification
• Booking: clinics, barbershops, garages — calendar, slots, reminders
• Support: triage of incoming questions and handover to a human agent
• Notifications: new enquiry, new lead, failed payment, low stock
• Internal bots: IT tickets, approvals, reports, visitor passes
• A Mini App shopfront with checkout, without leaving Telegram

For physical goods and services the route is familiar: the provider is connected in @BotFather, the bot receives a provider_token, the invoice goes out via sendInvoice, and the money lands in the merchant's account in som. Telegram itself charges no commission on the Payments API — you pay the provider only. Sometimes we deliberately take a different route and generate a Payme or Click checkout link delivered as a button. It costs one extra tap, but refunds, reconciliation and instalments stay inside the merchant dashboard, where your finance team already knows how to work.

Digital goods follow a completely different rule, and in Tashkent people usually discover it after launch. Since Bot API 7.4, anything sold inside a bot as digital — course access, a subscription, paid content — must be transacted in Telegram Stars: currency XTR, provider_token left empty. Payme and Click cannot be attached to that flow at all. On top of that, if the same course is sold on your website, Telegram requires it to be purchasable for Stars as well — a direct consequence of App Store rule 3.1.3(b). Stars are withdrawn through Fragment, which gives the model its own economics and its own currency exposure. That belongs in the unit economics before the first line of code, not after.

A bot with no integrations is a handsome contact form, and people stop using it within a month. Value appears when an order placed in Telegram becomes a deal in the CRM, a document in 1C and a task assigned to a named manager. We tie a Telegram user to a record in your system through a deep link of the form t.me/yourbot?start=payload — far more reliable than asking a customer to type an order number.

One constraint is worth understanding before anyone signs. Telegram does not let a bot message first: until the person taps Start or opens a deep link, no chat_id exists and there is nowhere to send the notification. Which means the brief "we will broadcast to our phone database" is impossible in principle, at any budget. There is exactly one workable pattern — capture the subscription at the moment the customer is already present: a QR code on the receipt, a button on the site, a link in the SMS that follows an order.

• amoCRM and Bitrix24 — via webhooks and the open API
• 1C — via HTTP services or OData
• Payme and Click — invoicing and transaction status
• Google Sheets — when there is no CRM yet but order is needed now
• IP telephony on Asterisk and compatible PBXs
• In-house systems — over REST, where documentation exists

Telegram caps throughput hard: no more than one message per second into a single chat, roughly 20 messages per minute into a group, and around 30 messages per second across an entire broadcast. The arithmetic that follows is simple and unwelcome — a list of 50,000 subscribers at 30 messages per second takes about 28 minutes to clear, and that is the ideal case with no retries. So a broadcast, in our builds, is always a prioritised queue with proper handling of the 429 response, never a loop over a list of recipients. Where higher throughput is genuinely required, paid broadcasts are enabled in @BotFather — up to 1,000 messages per second, with every message beyond the free thirty costing 0.1 Stars.

The remaining limits look like footnotes right up to the moment they collide with a finished scenario. We raise them during design, not at handover.

• A bot can delete its own message only within 48 hours — any "recall the promo" scenario must be designed for in advance
• In a group with privacy mode on, a bot sees only commands addressed to it; turning it off changes both privacy and load
• Webhooks require HTTPS on port 443, 80, 88 or 8443 — on cheap shared hosting this is usually the blocker
• From 20 July 2026, Mini App methods only work from the app's original domain: moving to another origin means rebuilding
• The Bot API ships several times a year (10.0 in May, 10.1 in June, 10.2 in July 2026) and libraries do not always keep pace

We write bots in Python with aiogram 3 or in Node.js, keep data in PostgreSQL, hold dialogue state and broadcast queues in Redis, package everything in Docker and run it over webhooks behind nginx. Deployment goes to your server or ours, your choice. We build an admin panel every time, even on small projects: a bot where no member of staff can change a price, a text or a schedule is dead within a month.

And there is one thing no web studio in Tashkent will offer. i7 Team does both software and infrastructure — networks, access control, CCTV, point-of-sale. So our bots talk to more than a CRM; they talk to hardware. Open a turnstile for an employee at the tap of a button, push a camera snapshot on an alarm, return the day's takings straight from the till system. That seam normally sits between two contractors and one argument about whose responsibility it is. Here there is one contractor.

• Source repository and deployment instructions handed to you
• Admin panel for content, prices, schedules and broadcasts
• Localisation in Russian, Uzbek and English, chosen at /start
• Monitoring on webhook errors, queue depth and 429 responses
• Formal handover of bot ownership with an access check