Как создать 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 или сразу бот.