Telegram bots and Web3 Mini Apps
We turn the messenger into a full application: a shop, an account, a wallet — all inside Telegram, with nothing to install.
- PostgreSQL
- and Redis at the core of the architecture
- TON / ETH / TRON
- supported networks
- 0 installs
- the user never leaves Telegram
A Mini App removes the most expensive step in any mobile product: installation. The user is already in Telegram, so the journey from ad to payment fits into a few taps. For e-commerce and service businesses that often converts better than an app of your own that has to be downloaded first.
We build these products as proper web applications with real architecture, not as scripts thrown together. The difference shows the moment traffic arrives and every second of response time starts costing money.
What the work includes
Telegram Mini Apps
A web application inside the messenger with a full interface: catalogue, basket, payment, personal account. It looks and behaves like a native app.
Bots built for load
Architecture on PostgreSQL and Redis, task queues, caching. A bot like that survives a traffic spike after a large placement instead of falling over at the first thousand concurrent users.
Payments
Card acquiring and crypto processing, both with proper error handling and payment reconciliation.
Web3 integrations
Wallet connections and smart-contract interaction on TON, Ethereum and TRON.
Admin panel and analytics
A control panel for content, orders and broadcasts, plus event analytics so you can see where users drop off.
How we work
1. Specification
We describe the user journeys and the boundaries of the project. The most expensive changes are the ones that arrive after development starts.
2. Design of the system
Data schema, choice of queues and caching, an estimate of expected load. We build the architecture for growth, not for the first week.
3. Interface
Design that follows Telegram's rules: light and dark themes, keyboard behaviour, window height limits.
4. Development and testing
In iterations, with demos along the way. Load testing happens before launch, not after a crash.
5. Launch and support
Monitoring, logs, incident response. Then improvements based on how users actually behave.
Mini App or a regular bot
A button-based bot is cheaper and faster to build. It works well where the journey is linear: book a slot, get a file, leave a request.
You need a Mini App when there is too much interface for buttons: a catalogue with filters, a basket, a personal account, order history. Trying to assemble that from buttons ends in a tree of dozens of menus that users get lost in.
A practical rule of thumb: if you're sketching a journey and it has more than three levels of nesting, it's time to think about a Mini App.
Why bots fall over under load
The most common cause is synchronous handling. The bot receives an update, goes to the database, waits for an external API and only then replies. While it waits the queue grows, Telegram starts resending updates, and the load multiplies itself.
The second cause is no caching. Every button press goes to the database for the same data. At a hundred users nobody notices; at tens of thousands the database becomes the bottleneck.
So we move long operations into queues, cache everything in Redis that doesn't change by the second, and reply to the user immediately while the heavy work happens in the background.
What to get right about payments
Payment is the one place where a mistake costs real money and reputation. It needs idempotency, so a repeated request doesn't charge twice, and reconciliation, so discrepancies between your database and the processor surface automatically.
Crypto adds volatility and network confirmations. We fix the rate at the moment of payment and show transaction status, so the user doesn't press the button again while the block is still confirming.
Other services
Frequently asked
questions.
It depends on scope. A simple storefront with payment takes a few weeks; a full shop with accounts and integrations takes longer.
Yes, given access to the code and the database. Sometimes rewriting the core is cheaper than patching something that can't take the load.
You do. We hand over the repository and documentation with the project.
Both. We often run the product and its promotion together — that way it's clearer what actually needs improving.
Let's talk about your product
Tell us what the bot or app needs to do — we'll come back with an estimate of scope and timing.
You can also reach us here