Telegram bots for business: when they beat a web app

I have shipped a lot of Telegram bots for businesses. For the right problem they out-convert and out-retain a web app at a fraction of the build cost. For the wrong problem they are a frustrating dead end that wastes a quarter. The difference is almost always in the shape of the workflow, not the industry.

When a bot wins

A Telegram bot is the right surface when most of these are true:

• The workflow is conversational by nature — alerts, approvals, lookups, quick captures
• The user already lives in Telegram all day (eastern Europe, crypto, logistics, agencies)
• You need to ship in days, not weeks
• Authentication and notifications should be free, instant, and zero-setup
• The actions are short and high-frequency: under 30 seconds, multiple times a day

The killer feature is no install, no login, no app switch. The user is already in Telegram. The bot is one tap away. Conversion from "I heard about this" to "I used it" is the highest of any product surface I have worked with — often above 70% from a direct link.

When a bot loses

A bot is the wrong surface when:

• The workflow needs rich tables, charts, or long multi-step forms
• You need precise design control or brand-led UI moments
• Users are not Telegram-native (US-only B2B, enterprise procurement)
• The action is rare and high-stakes (annual contract review, onboarding flows)
• You need offline support or background sync

The mistake teams make is forcing a tabular workflow into a chat surface. Once you are nesting inline keyboards three levels deep to simulate a table, you have built a worse web app inside Telegram. Just build the web app.

The hybrid pattern that wins

The best setups I have shipped use the bot as the primary surface for daily actions and a small web dashboard for setup, analytics, and admin. Telegram for speed, web for depth.

A concrete example: a logistics company I built for uses a bot for drivers to log pickups, scan receipts, and request route changes. The dispatcher uses a web dashboard to assign jobs, see the map, and export reports. Same backend, two surfaces, each tuned to its user.

How to build it

A typical stack:

1. Bot framework: grammY (TypeScript) or aiogram (Python). Both are mature; pick by your team's language.
2. Webhook server: a single endpoint behind a reverse proxy. Avoid long-polling in production — webhooks are simpler to scale and easier to monitor.
3. State: do not put conversation state in memory. Use Postgres or Redis so a restart does not drop mid-flow users.
4. Admin layer: a tiny React + TanStack Start dashboard for setup, audit, and analytics. This is where you spend the polish budget.

What it costs

A focused single-flow bot ships in 3–5 days. The hybrid bot + dashboard pattern typically takes 3–4 weeks for a real production system with auth, audit logs, and a small admin UI. Compare that to 8–12 weeks for the same workflow as a full web app, and the math is obvious for early-stage teams.

The trap is not the bot. The trap is treating it as a permanent ceiling. Build the bot to validate the workflow, then add the web surface where it earns its keep.