Як створити Telegram Mini App у 2026: шлях від прототипу до 60 000 користувачів на день

Telegram Mini Apps виросли з експериментальної фічі у повноцінну платформу: 200 мільйонів користувачів відкривають їх щомісяця, і це найшвидший спосіб дистрибуції продукту в месенджері. Ми запустили The Open Earn на початку 2024 року і за півтора року довели його до 60 000 щоденних користувачів та 500 000+ виконаних завдань. Цей гайд — про те, як ми це зробили і що порадили б собі на старті.

Mini App vs звичайний бот: коли що обирати

Telegram Bot — це діалоговий інтерфейс через повідомлення. Telegram Mini App — це повноцінний web-застосунок, який відкривається у вікні Telegram і має доступ до API месенджера.

Звичайний бот підходить, коли:

• Сценарій лінійний: команди → відповіді (гарант-бот, бот-сповіщення)
• Мінімальна UI-складність
• Важлива швидкість прототипу

Mini App потрібен, коли:

• Складний UI з навігацією, формами, списками
• Потрібна інтерактивність у реальному часі
• Платежі через Telegram Payments або Stars
• Каталог товарів, профіль користувача, стрічка

У The Open Earn у нас і те, і інше: бот для сповіщень та онбордингу, Mini App для основного інтерфейсу з балансом, виведенням та статистикою.

Стек: що ми використовуємо

Прозоро перелічимо продакшн-стек The Open Earn:

Frontend (Mini App):

• Next.js 16 (App Router, SSR) — для швидкості першого рендера та SEO лендингу
• React 19 + TypeScript
• @twa-dev/sdk — обгортка над Telegram Web Apps SDK (тема, viewport, події)
• TonConnect SDK — для підключення TON-гаманця

Backend:

• Python 3.12 + FastAPI — API-сервер
• aiogram 3.x — бот
• PostgreSQL 16 — основне сховище
• Redis — кеш сесій, rate-limiting, pub/sub для воркерів
• Celery — фонові задачі (виплати, перевірки завдань)

Інфраструктура:

• Один dedicated-сервер (8 GB RAM, 4 vCPU)
• nginx як реверс-проксі
• PM2 для Node-процесів, systemd для Python
• Let's Encrypt для SSL

Цього достатньо до 50–100K DAU. Дорожчим стало лише коли підросли до 60K — довелося винести Postgres на окремий managed instance.

Авторизація: initData і серверна валідація

Головна помилка новачків — довіряти даним з Telegram.WebApp.initDataUnsafe. Їх можна підробити в DevTools.

Правильний процес:

1. Mini App при старті отримує initData (raw string) від Telegram через JS SDK
2. Надсилає його на ваш бекенд у заголовку Authorization: TelegramInitData ...
3. Бекенд валідує підпис через HMAC-SHA256 від bot token
4. При валідному підписі — витягує user.id, видає сесійний токен

Псевдокод валідації на Python:

import hmac, hashlib
from urllib.parse import parse_qs

def validate_init_data(init_data: str, bot_token: str) -> dict:
    parsed = parse_qs(init_data)
    received_hash = parsed.pop("hash")[0]
    data_check = "\n".join(f"{k}={v[0]}" for k, v in sorted(parsed.items()))
    secret = hmac.new(b"WebAppData", bot_token.encode(), hashlib.sha256).digest()
    expected = hmac.new(secret, data_check.encode(), hashlib.sha256).hexdigest()
    if not hmac.compare_digest(expected, received_hash):
        raise ValueError("Invalid signature")
    return parsed

Також перевіряйте auth_date — відкидайте сесії старші за добу (захист від replay-атак).

Платежі: Stars, TON, USDT

У Telegram-екосистемі зараз є три способи приймати гроші:

1. Telegram Stars (для цифрових товарів) — через Bot API: sendInvoice з currency: "XTR". Тільки для intangible-покупок. Telegram утримує комісію ~30%.

2. TON напряму — через TonConnect: користувач підключає гаманець, підписує транзакцію. Комісія — десяті частки цента.

3. USDT у TON-мережі (Jetton) — те саме, що TON, але у стейблкоїні. Зручно для B2B та розрахунків з фіксованою ціною.

У The Open Earn ми виводимо заробіток у USDT через TonConnect — користувач бачить суму в доларах, а не у плаваючій ціні TON. Мінімум — $1.

Деплой і масштабування

Найпростіша прод-схема для старту (до 10K DAU):

[Cloudflare] → [nginx] → [Next.js на :3000] → [FastAPI на :8000] → [Postgres]
                                                ↓
                                            [Redis]

Що зламалось у нас на 30K DAU і як лагодили:

• Postgres connection pool закінчувався — додали pgbouncer і розвели read/write
• Redis OOM при піках — збільшили maxmemory, поставили allkeys-lru
• Latency бота на webhook — прибрали важкі перевірки у фон через Celery
• CDN для статики — винесли в Cloudflare R2

Головне правило: вимірювати, а не вгадувати. Sentry для помилок та Grafana + Prometheus для метрик з першого дня.

Що б ми зробили інакше

Якби робили Mini App заново, у день 1 ми б:

1. Одразу розділили моноліт на 2 сервіси — публічний API і приватний (адмінка/воркери). Об'єднати дешевше, ніж розділити потім.
2. Поставили feature flags (Unleash, GrowthBook) — стало б у нагоді для A/B-тестів на етапі росту.
3. Використали Server Actions Next.js замість свого REST-шару для простих форм. Менше коду.
4. Не витрачали час на красиві анімації у день 1 — користувачі приходять за функцією. Поліровка має сенс після product-market fit.
5. Одразу заклали i18n-інфраструктуру — переклади 12 мовами додали нам 4× трафіку, але додавати їх до робочого продукту — біль.

Що далі

Mini Apps у 2026 — це вже не «експеримент Telegram», а серйозний канал дистрибуції. Якщо у вас є продукт, який перетинається з активною аудиторією месенджера, — варто принаймні спробувати. Стартовий стек мінімальний, ризик нижчий, ніж у нативного мобільного застосунку.

Якщо хочете побачити, як Mini App працює у продакшні — відкрийте The Open Earn або одразу бот.