Кейс EdTech-платформы JUVOSpark: единая точка входа в Telegram, invite-only онбординг преподавателей, изоляция данных, тесты, расписание, домашки и JWT-админка. Инженерный подход и стек.
Изначальная задача была точечной: автоматизировать процесс обучения учеников — прежде всего прохождение тестов с уровнями, таймером, фидбеком и результатами без ручной проверки. Из этого контура продукт вырос в полноценную EdTech-платформу: расписание, домашки, оплаты и напоминания, поддержка, веб-админка и invite-only масштабирование на преподавателей в одном боте.
JUVOSpark — это EdTech-платформа, в которой образовательный сценарий для ученика живёт в Telegram, а операционка преподавателя и владельца платформы — в веб-админке на защищённом Admin API.
Платформа закрывает не одну «фичу бота», а связку процессов: тестирование, расписание, домашние задания, учёт оплат, напоминания, поддержку и контролируемое масштабирование на преподавателей.
Ключевой продуктовый принцип простой и жёсткий:
Один общий бот — единая точка входа. Разделение по преподавателям делается через invite и deeplink, а не через отдельных ботов.
Когда команда говорит «нужен бот для обучения», обычно имеют в виду меню, пару сценариев и рассылку. На практике EdTech-продукт очень быстро упирается в операционные вопросы:
Если эти вопросы не заложены в архитектуру с первого дня, продукт либо остаётся «демо-ботом», либо начинает обрастать костылями: отдельные боты на каждого преподавателя, ручные таблицы, чаты без статусов, доступы «всем подряд».
Именно поэтому JUVOSpark проектировался не как чат-виджет, а как платформа с ясной моделью входа, ролей и изоляции.
Самая частая ошибка — масштабировать продукт копированием ботов.
Новый преподаватель — новый бот.
Новая группа — ещё один токен.
Новый бренд внутри сети — ещё один инстанс.
Через несколько месяцев уже сложно уверенно ответить:
Типичные anti-patterns, которые мы сознательно исключили:
Отсутствие ответов на эти вопросы превращает рост в хаос сопровождения. Поэтому в JUVOSpark выбран другой путь: один бот, invite-only рост, изоляция данных.
Нужна была EdTech-платформа, где:
Цель v1 — не «закрыть все EdTech-мечты», а собрать устойчивый контур: образование + операции + масштабирование на teachers.
Ученик всегда заходит в один и тот же бот платформы. Это единый бренд-канал, единый UX и единая точка обновлений.
Есть два сценария входа:
Преподаватель не регистрируется в админке сам. Доступ выдаёт owner:
Так платформа растёт без open signup и без антиспам-слоя «на всём интернете», сохраняя контроль owner над тем, кто вообще получает рабочее пространство.
В модели v1 есть три ключевых роли:
Важное UX-правило: если пользователь одновременно teacher и student, в боте он всегда видит student-flow. Управление для преподавателя живёт в веб-админке. Это снижает путаницу и не превращает Telegram в «вторую админку».
Образовательный контур в Telegram собран как цельный сценарий, а не набор разрозненных команд.
После /start ученик получает меню:
То есть Telegram здесь не «витрина», а рабочий канал обучения и сервиса.
Отдельный слой платформы — операционные сценарии прямо в Telegram для платформенного администратора.
В Admin Panel бота доступны:
Дополнительно в фоне работают ежедневные напоминания об оплатах и уроках. Это важно: платформа не только отвечает на действия пользователя, но и сама поддерживает ритм обучения и оплаты.
Именно этот слой делает бота не демо-меню, а управляемым каналом продукта.
Параллельно с ботом работает веб-админка на JWT-защищённом REST API. Один backend обслуживает и Telegram long polling, и HTTP API — без рассинхрона доменной логики.
Из админки управляются:
Google Calendar подключается через OAuth как интеграция календаря преподавателя; полный двусторонний sync выносился поэтапно, чтобы не блокировать основной контур.
Проект строился по Clean Architecture: домен не зависит от Telegram и HTTP, а инфраструктура подключается через интерфейсы. Это позволило развивать бот и админку параллельно на одном ядре.
Для Telegram-нагрузки важны:
Для доступа в админку — JWT с ролевой моделью owner/teacher.
Для данных — SQLite с предсказуемой схемой под education-domain и invite/binding.
Для поставки — Docker, reverse proxy, CI-образы, контролируемые обновления.
Это не «оверинжиниринг ради красоты». Это минимальный набор практик, без которых multi-teacher EdTech на одном боте быстро становится хрупким.
Исходная точка проекта была уже не blank page: был живой Telegram-контур и инженерная база. Задача состояла в том, чтобы вырастить из него полноценный EdTech-продукт с понятной моделью масштабирования.
Что сделали по сути:
Перед каждым архитектурным решением проверяли один критерий: усложняет ли это сопровождение при росте числа преподавателей. Если да — искали модель проще. Так и появился принцип «один бот + invites», а не «бот на каждого».
Самое опасное решение в такой задаче — ускориться за счёт копирования инстансов.
Отдельный бот на преподавателя выглядит быстро только в первую неделю. Дальше растут:
Безопасный путь масштабирования, который мы заложили:
Именно такая последовательность делает рост обратимым и контролируемым. Формулировка «поднимем ещё одного бота» в зрелом EdTech обычно означает будущий операционный долг.
Такой подход даёт сразу несколько эффектов:
Для портфолио и для заказчика здесь важен не список кнопок, а то, что платформа умеет расти, не разваливаясь на набор чатов.
Сильный Telegram-EdTech начинается не с меню кнопок, а с модели входа и роста. Если сразу заложить «отдельный бот на каждого», продукт ускорится на неделю и замедлится на годы сопровождения.
JUVOSpark построен иначе: один общий бот как единая точка входа, invite-only подключение преподавателей, персональные deeplink для учеников, изоляция данных и веб-админка для операционки. Поверх этого — полноценный образовательный сценарий: тесты, расписание, домашки, напоминания и поддержка.
Такой дизайн делает платформу понятной для ученика, управляемой для преподавателя и масштабируемой для владельца — без зоопарка ботов и без хаотичной публичной регистрации.
Если нужен EdTech-контур в Telegram с контролируемым multi-teacher ростом, начинать стоит не с копирования ботов, а с карты ролей, точки входа и правил привязки учеников.
Дальше — домен обучения, admin API и только потом интеграции и платёжный шлюз.
Точечная задача — автоматизировать прохождение тестов в Telegram — выросла в цельный EdTech-контур. Ученик получает обучение и сервис в одном канале: тесты с уровнями и фидбеком, расписание, домашки, контакты и поддержку без переключения между чатами и таблицами. Для преподавателя и владельца платформы операционка вынесена в веб-админку: контент, ученики, уроки, оплаты, уведомления и аналитика — в одном месте, а не в разрозненных инструментах. На уровне платформы заложена модель контролируемого роста: один общий бот как единая точка входа, invite-only подключение преподавателей и персональные deeplink для учеников с изоляцией данных. Один backend обслуживает и Telegram, и Admin API, поэтому логика не расходится между каналами. Продукт доведён до production-контура — контейнеры, фоновые напоминания, поддержка и масштабирование на teachers без зоопарка отдельных ботов.