Как я начал делать Telegram-бота с нуля и почему “бот” — это не про код
Когда я начинал, в голове это выглядело так: “Сделаю бота → подключу оплату → всё будет работать”.
Реальность оказалась другой. Бот — это вообще не про кнопки и сообщения. Бот — это про процессы: кто, когда, за что платит, что ему выдать, что делать если что-то пошло не так, и как не утонуть в поддержке.
Я решил сделать сервис, где бот:
- принимает оплату,
- выдаёт доступ,
- следит за сроком,
- продлевает/останавливает,
- и не требует от меня ручных действий “каждому по чуть-чуть”.
Звучит просто, но именно на этом месте многие и ломаются.
С чего я реально начал (и это было правильное решение)
Я не писал код первым делом. Я сначала зафиксировал требования и границы проекта, иначе всё превращается в бесконечное “а давай ещё вот это”.
1) Что должно уметь “MVP” (минимум, без которого смысла нет)
Пользователь:
- зайти в бота и понять, что делать дальше,
- выбрать период/вариант,
- оплатить,
- получить доступ автоматически,
- увидеть дату окончания и статус,
- продлить без переписки со мной.
Админ:
- видеть список пользователей и их статус,
- быстро находить человека по id/нику,
- продлевать/отключать вручную (на крайний случай),
- видеть события: оплаты, ошибки, выдача, продления.
2) Что я сознательно выкинул из “первой версии”
И вот это важный момент. Я прям списком написал “не делаем сейчас”, чтобы не расползаться:
- реферальная система,
- промокоды и скидки,
- мультивалюты,
- сложные тарифные сетки,
- красивая админка “как у больших”.
Почему? Потому что если базовый сценарий “оплата → выдача → работает” нестабилен, любые фичи — мусор сверху.
Главная штука, которую я понял ещё до кода
У бота есть “ядро”, которое люди не видят
Пользователь видит кнопки. А проект держится на том, чего не видно:
- состояния платежа,
- дедлайны,
- что делать при сбое,
- что делать при повторной оплате,
- что делать если человек оплатил, но не получил доступ,
- что делать если уведомление от платежки не пришло,
- как не выдать два раза,
- как не забыть отключить по сроку.
Если эти ответы не прописать заранее, дальше начинается ручной ад: “ща исправлю”, “ща посмотрю”, “ща выдам”, “ой, снова”.
Как я описал логику на бумаге (без технарщины)
Я завёл табличку из трёх колонок:
Событие → Что должно произойти → Что делаем если ошибка
Пример (упрощённо):
- “Пользователь нажал оплатить” → создаём счёт, ставим статус “ожидаем” → если не оплатил за X минут, счёт протухает
- “Оплата успешна” → выдаём доступ, ставим срок, отправляем инструкцию → если выдача не сработала, ставим “ошибка выдачи” и уведомляем админа
- “Срок закончился” → отключаем доступ → если отключение не прошло, повторяем и логируем
И вот с этого момента проект стал понятным: я видел, что должен написать, и где заранее поставить страховки.
Почему я вообще делаю эту серию постов
Потому что большинство разборов в интернете заканчиваются на “вот код бота”, а дальше — тишина. А самая жесть начинается после: оплаты, статусы, поддержка, стабильность.
В следующих постах я пойду по шагам — прямо как строил:
- архитектура на салфетке: сущности, статусы, сценарии,
- затем каркас бота,
- затем оплаты и все “крайние случаи”,
- затем выдача и сроки,
- затем онбординг,
- и только потом красота.