There is an intercity bus service whose passengers organised themselves in a Telegram group of about 4,000 members. Schedule questions, "is the 06:30 running", seat requests, driver phone numbers, lost items, complaints — all in one stream, all scrolling away within the hour. That road is part of my week — PFC AGMK, where I work, sits at one end of it — and the chat was on my phone long before it became a product.
The obvious answer was an app. We did not build one first. This note explains why, what we built instead, and when an app becomes the right next step — a playbook we now apply to every consumer product before writing a line of native code.
Why not an app first
Three reasons, in order of importance.
- Everyone is already in Telegram. Passengers, drivers and dispatchers used the chat daily. Asking them to install something new, create an account and learn a new interface is a cost paid by every single user before the product delivers anything.
- Distribution is solved. A bot is a link. It can be pinned in the existing chat, forwarded to a relative, printed as a QR code on the bus door. No store listing, no review queue, no updates to nag about.
- Identity is free. A Telegram account already has a verified phone number. No registration screen, no SMS codes, no forgotten passwords — the single biggest drop-off point in any local app is simply gone.
A native app costs considerably more to build than a Telegram Mini App, and a plain bot costs less still. Building the bot first is not only cheaper, it answers the question an app cannot answer until it is built: do people want this enough to change a habit.
What we built
A bot for the conversational parts and a Mini App for the parts that need a screen.
- Schedule and next departure as the first button, because that was the most repeated question in the chat.
- Seat requests as a structured flow instead of a message the dispatcher may or may not see.
- Announcements — delays, changed departures — pushed by the dispatcher to subscribers, not typed into a chat where they scroll away.
- A subscription for regular passengers, paid through Payme or Click inside Telegram, so the operator has predictable revenue and the passenger has a fixed price.
The chat did not disappear overnight. The bot took over the transactions; the chat kept the conversation.
UX for every age
The audience is not a startup audience. It is students, workers, grandparents visiting family, people on their first smartphone. The design rules that came out of this:
- One question per screen. Where, when, how many. Never a form.
- Big buttons, plain words. Uzbek Latin and Russian, chosen once, remembered. No icons without text.
- No dead ends. Every screen has a way back and a way to reach a human — the dispatcher — inside the same bot.
- Confirm in words the passenger would say. "Ertaga 06:30, 2 oʻrin" repeated back before payment.
- Test on the oldest phone you can find. Not the newest. A Mini App that works on a five-year-old Android on a weak connection works for everyone.
Subscriptions
A subscription is the point where a community chat becomes a business. The rule that matters: the passenger should never have to think about it. Pay once inside Telegram, get a confirmation in the chat, get reminded three days before it ends, renew with one tap. The operator gets a list of who is paid up — the same list that used to live in a notebook. We publish subscriber numbers only once they are measured; until then every number about this product on this site is marked as a target.
When to graduate to an app
A Telegram product should become a native app when — and only when — one of these is true:
- You need the device, not the chat. Background GPS to show the bus on a map, offline tickets, hardware integrations. For that, the app has to live on the phone itself.
- Notifications need to be yours. In Telegram, your alert arrives alongside every other chat. If a missed notification means a missed bus, you need your own channel.
- The subscriber base pays for it. When recurring revenue covers what the app costs to build, and a year of maintenance after it, the app is an investment. Before that it is a bet.
- A partner requires it. Some corporate or public-sector contracts ask for a listing in the stores.
When that day comes, the app is built on the same backend, with the same subscriptions and the same users. Nothing is thrown away; the bot keeps running for the people who prefer it. That is the whole playbook: prove the demand where people already are, then follow them to the device when the numbers say so.
If you have a chat that has become a business — a school, a clinic, a delivery route — contact us and we will map which parts should become a bot first and which can wait.