In Kazakhstan, Telegram boasts over 10 million active users per month, while Kaspi.kz has around 13 million: together, these two infrastructures cover almost the entire adult population of the country. Meanwhile, the average business here continues to think in terms of 2018: "we need a mobile app." Tenders for developing iOS and Android versions start at 8–12 million tenge, take 6–9 months, end up on the App Store and Google Play, and then 80% of installations don't survive the second week. And all this for functionality that a Telegram bot assembles in a week.
At West Star Ltd, we conduct integration projects using Python/Django and regularly encounter the same scenario: the client initially comes for an app but leaves with a bot—and three months later realizes they don't need the app at all. It's not about the trend of bots or cost-effectiveness. It's about the fact that for most B2B scenarios in Kazakhstan, the "messenger channel + payments via Kaspi" model functionally surpasses a mobile app in all measurable parameters except one. More on this exception at the end.
Why Native Apps Have Stopped Being the Obvious Choice
The standard cost of developing a commercial mobile app in Almaty and Astana today is 8–15 million tenge for an MVP with basic functionality on two platforms. The timeline is from six months to a year, including passing moderation in the App Store. Added to this is the annual support cost (15–25% of the development budget), the fee for an Apple developer account ($99/year) and Google Play ($25 one-time), and the perpetual hassle with SDK updates, new privacy requirements, and compatibility with new versions of iOS and Android.
Then comes the worst part—installations. For a client to use the app, they need to: open the store, find it (or follow a link you sent them somewhere), wait for the 80–150 MB download, allocate space in memory, agree to permissions, register, and confirm their email or number. According to industry statistics, between "saw the ad" and "opened the app for the first time," 60–80% of the audience is lost. In the B2B segment, where the client pool is already narrow, this is catastrophic.
A Telegram bot bypasses this logic differently. The client is already on Telegram. No registration, no installation, no permissions. One click on a link—and they're inside. Zero friction at entry. Identification, if necessary, is done via request_contact—the user shares their number with one click, and the same number is linked to the Kaspi account, to the contract in 1C, to the client base in CRM. A closed identification loop, for which an app would require SMS verification with its cost of 15–25 tenge per message.
What Kaspi Pay Changed in This Equation
Until 2024, the key limitation of bots was precisely payment acceptance. One could either ask to send receipts in the chat and verify them manually or integrate third-party acquiring with a 2.5–3.5% commission and its own onboarding for the client. Now the situation is different. Kaspi has a direct API for businesses (Kaspi Pay for entrepreneurs), which allows generating QR codes and invoices with automatic webhook notifications of payment. Simultaneously, an ecosystem of intermediaries—AiPay, Pay.Aibot.kz, and similar—has developed, simplifying connections for those who don't want to negotiate directly with the bank.
Technologically, this means the scenario "client writes to the bot → bot issues an invoice via Kaspi → client pays in one click in their Kaspi app → bot receives a webhook and moves to the next step" works in 4–8 seconds without operator involvement. For a restaurant, this means order acceptance without a manager. For a wholesale company—shipment on prepayment without accounting support for each transaction. For a service business—subscription fee acceptance.
Previously, this same chain required at least two people on the seller's side, a separate app with payment system integration, certification, and a three-to-four-month implementation cycle. Now—one developer and a week's work.
Where the Bot Works Best
If you strip away the marketing wrapper, typical B2B scenarios where a Telegram bot outperforms an app fall into four categories.
Applications and tickets. The client sends an application, it's routed to a manager, the manager responds, and the client receives a notification. That's the entire functionality—and both the app and the bot serve it equally. Only the bot is written in 5–10 working days by one developer, while the app requires a three-month sprint.
Data entry and verification via 1C. A warehouse manager scans a barcode through the bot, the bot requests stock via OData, returns the quantity and current reserve. Previously, mobile apps with terminal server connections were written for this. Today—one function in the bot plus an OData endpoint, and the manager uses it right in Telegram, which is already open.
Subscription and membership models. Access to paid content, KPI calculation, reports, analytics, expert consultations. The bot issues a monthly invoice via Kaspi, opens access upon payment, and closes it upon overdue. No App Store with its 30% commission. No separate payment pages on the website.
Notifications and operations. Orders, statuses, contracts for approval, payment reminders, KPI reports. Here, the bot not only competes with the app—it devours it. Push notifications in apps have a 3–8% open conversion; a message in Telegram—60–80%, because the messenger is opened every 15 minutes, while the app—once a week.
Real Project Economics
Let's take a specific scenario: a trading company, 200 regular B2B segment clients, needs to automate order acceptance, invoice issuance via Kaspi, and payment reconciliation with 1C.
In the native app format: 10 million tenge for development (iOS + Android), 6 months to release, 2 million tenge per year for support. A year after launch, the app is installed by 40–60% of the client base, actively used by 25–35%. Return on investment—questionable.
In the Telegram bot format: 600–900 thousand tenge for development (Python + aiogram + integration with Kaspi API + OData connector to 1C), 1.5–2 months to release, 150–250 thousand tenge per year for support. Two weeks after launch, the bot is available to 100% of the client base (no installations). Active usage—70–85%, because Telegram is always open for these people.
The budget ratio is approximately 1:15 not in favor of the app. The coverage ratio is 1:2 in favor of the bot. The timeline ratio is 1:4. This arithmetic breaks almost all arguments for an app in a typical B2B scenario. And this is not a comparison of "cheap craft against a quality product"—the functionality is comparable. The difference is that the bot uses someone else's infrastructure (Telegram + Kaspi), while the app requires building your own.
The Technical Stack That Really Works in Kazakhstan
For a production bot in the Kazakhstani B2B market, the stack has stabilized. The basis is Python with the aiogram 3.x library (asynchronous, supports all current Bot API capabilities). The database is PostgreSQL for transactional data and Redis for caching and rate-limiting. Deployment is Docker on a VPS with a local provider or Hetzner for geographical proximity (important for Kaspi webhook speed).
For integrations, two layers are critically important. The OData connector for 1C—this allows the bot to read stock, orders, and counterparties in real-time and create documents if necessary. The scale economy here is enormous: 1C is installed in the overwhelming majority of companies in Kazakhstan, and the layer between it and the Telegram bot pays off with the first client. The second layer is the Kaspi Pay API via webhook to your backend, because direct connection provides flexibility that intermediaries don't have.
For more complex scenarios—Telegram Mini Apps. These are HTML/JS applications that open right inside Telegram without going to the App Store. Suitable for catalogs, carts, personal accounts with a tabular interface, which are hard to fit into the format of messages and buttons. Assembly takes 1.5–2 times longer than a pure bot, but still remains significantly cheaper than a native app.
Where This Approach Really Doesn't Work
Before selling a bot instead of an app to a client, it's important to honestly outline the boundaries.
Scenarios with intensive graphics and video. If your product is, for example, a learning platform with streaming video, a library of design assets, or a tool for image editing, the Telegram interface will be cramped. Mini Apps partially solve this, but the "heavy" UX in a messenger window still feels like a compromise.
Games and products with pronounced gamification. Here, the app provides such a better UX that the difference outweighs all economic considerations. Bots can work as an attraction and retention channel, but not as the main interface.
Offline-first usage. Courier apps, warehouse logistics in areas with poor coverage, fieldwork—need the interface to work without a network and sync when a connection appears. Telegram requires a connection for each operation.
Tied to specific device functions. NFC readers, special camera modes, biometrics for signing documents via NCALayer-like services. Some of this is solved through Mini Apps, but not all.
Brand presence. If it's critically important for a business to have a full-fledged icon on the client's home screen, a separate ecosystem, recognizability as "you have our app"—the bot doesn't provide this. It's an emotional factor, but sometimes it costs money.
Platform dependency. Telegram has been blocked in Russia and several other jurisdictions. In Kazakhstan, there are currently no such risks, but architecturally, a business built on top of a third-party messenger always carries the risk that the platform owner will change the rules, API tariffs, or policy. This risk doesn't exist with your own app.
What to Do
For most Kazakhstani companies in the small and medium segment, the typical task is to automate that part of client interaction that currently goes through WhatsApp, phone calls, and manually filled invoices. In this scenario, a Telegram bot with Kaspi Pay integration and 1C via OData covers 80% of the need at a budget 10–15 times less than an app, and an implementation timeline measured in weeks, not quarters.
The approach that works: start with a bot for 2–3 key scenarios (order acceptance, invoice issuance, order statuses), launch in 6 weeks, test on a real client base, and in 3–4 months—based on actual usage data—decide if an app is needed at all. In our practice (AI-accountant, OData Hub, warehouse integrations), this scenario repeats regularly: before launching the bot, the client firmly wanted an app, after three months of operational use—they don't even return to the idea.
A mobile app is a tool. Good, expensive, powerful. But like any tool, it's not suitable for all tasks. In Kazakhstan 2026, the question "do we need a mobile app?" is better formulated differently: "are there exactly those functions in our scenario for which it's worth paying 15 times more and waiting 4 times longer?" If the honest answer is "no," then the bot is not a compromise. The bot is the right choice.