В 2020 году мы рассказывали, как Константин Климентьев за 2 недели сделал на Glide сервис TutGood — платформу, на которой дети могут заниматься с репетиторами. Благодаря MVP, основателям удалось привлечь инвестиции на развитие идеи, и сервис переехал с Glide на Bubble. Егор Петров — team lead TutGood — рассказал, почему решили развивать продукт именно на Bubble, как оптимизировали отбор преподавателей и какие еще процессы автоматизировали с помощью зерокода.
О сервисе
TutGood
— платформа безлимитных занятий с репетиторами по подписке. На ней можно заниматься с учителями по 25 направлениям: от математики и русского языка до программирования, вокала и логопеда. Можно быстро получить помощь, если что-то непонятно по школьной программе, или изучать конкретный предмет.
Один из основателей сервиса — Константин Климентьев — собрал MVP продукта на Glide летом 2020 года. Так началось тестирование новой для России бизнес-модели, которая оказалась успешной. Сейчас на платформе занимается более 5 тыс. учеников, работает 1260 учителей, проводится около 2 тыс. занятий в день. В 2021 году выручка компании была 16,4 млн рублей, а в 2022 году она выросла до 150,2 млн рублей.
Сам продукт за время существования сильно изменился.
Перенесли платформу с Glide на Bubble
Как только основатели сервиса увидели, что люди готовы платить за него деньги, они решили перенести платформу на Bubble — у него больше возможностей. Преимущества развивать продукт и дальше без кода превысили недостатки: в стартапе постоянно что-то дорабатывается, тестируют разные гипотезы — внедрять все изменения на коде долго и дорого. Например, только на создание первой версии подобного сервиса нужно не менее 5 млн рублей.
«Для того чтобы поддерживать такую же скорость разработки на коде, какая у нас сейчас на Bubble, нужно в несколько раз больше разработчиков», — рассказывает Егор.
Если вы хотите попробовать себя в роли веб-разработчика без кода, записывайтесь на бесплатный двухдневный марафон. Мы расскажем о самом популярном инструменте Bubble и покажем примеры реальных веб-приложений, собранных на зерокоде.
Для переноса TutGood на новый инструмент основатели обратились в студию ноукод-разработки. Но эта попытка оказалась неудачной. На тот момент на платформе проводилось всего 2-3 урока в час, и даже при такой маленькой загрузке собранный на Bubble сервис начинал зависать. Тогда Константин решил нанять ноукодера в штат и пригласил сначала одного разработчика, а затем и Егора. Так, вдвоем ребята стали переделывать платформу, улучшать ее работоспособность и добавлять новые функции и процессы.
После миграции сервиса процесс обучения не поменялся: родитель записывает ребенка на занятие, а преподаватель отправляет в чат платформы ссылку на конференцию в Zoom, где проходит урок.
Собрали команду разработки
Постепенно в компании образовался технический отдел из 6 человек — они развивают и поддерживают платформу. Константин стал техническим директором и отвечает за продукт. Егор — тимлид, он лучше всех знает существующие процессы, поэтому составляет подробное ТЗ для остальных сотрудников, отвечает на вопросы и решает возникающие сложности. Помимо Константина и Егора, есть еще 4 разработчика, все — ноукодеры.
Часть команды настраивает процессы, другие — решают технические проблемы пользователей сервиса. Если у клиентов что-то не работает, они обращаются в отдел поддержки. В этом случае сотрудник поддержки заносит тикет через телеграм-бот, он попадает в таблицу в Airtable, где его подхватывают разработчики.
Оптимизировали отбор преподавателей
На платформе сейчас работает 1260 учителей, и их количество растет. Если нанимать и проводить обучение всех сотрудников вручную — на это уйдет масса времени. Поэтому основная задача разработчиков — максимально упростить воронку по найму людей.
За 2 года существования платформы процесс несколько раз менялся. Сегодня онбординг преподавателей идет через
WinWinbot. Вот как он выглядит:
Шаг 1. Соискатель заходит в телеграм-бот и заполняет анкету с личными данными. В этот момент автоматически создается ID пользователя в Airtable.
Шаг 2. Человек выбирает предмет, которому хочет обучать, и бот предлагает ему решить соответствующий профессиональный тест. Так можно проверить его знания.
Шаг 3. Если тест сдан, человек должен пройти обучение по использованию платформы. Для этого он нажимает на кнопку в боте и переходит на страницу в Bubble, где можно выбрать время обучения — будний день в 10.00 и 16.00 по московскому времени. Одновременно система создает аккаунт этого учителя в Bubble, чтобы он мог потом проводить уроки.
Шаг 4. Соискатель проходит обучение в Zoom, где ему рассказывают, как работать с платформой.
Когда Егор настраивал процесс, он хотел сделать путь пользователя максимально бесшовным. Это значит, что можно пройти все шаги друг за другом, и нигде не нужно ждать. Сегодня все работает именно так.
Все этапы онбординга преподавателей фиксируются в Airtable. Для этого используются вебхуки в WinWinbot. Дополнительно Егору пришлось написать скрипт на Python, потому что WinWinbot отключает вебхук, если не получает от него ответ в течение 5 секунд.
Автоматизировали процессы
На сегодняшний день возможностей самого дорогого тарифного плана Bubble хватает, чтобы проводить около 2 тысяч уроков в день. Во многом благодаря тому, что разработчики максимально автоматизировали все процессы. Например, были сложности из-за того, что преподавателей много, у каждого свои рабочие часы, на которые может записаться ученик — Bubble было сложно поддерживать стабильную работу.
Чтобы процесс затрагивал меньше мощностей инструмента, разработчики сделали вспомогательную таблицу, в которой указаны только рабочие часы по конкретному предмету и для одной категории учеников. Например, в ней есть только доступные слоты для обучения математике дошколят. В результате когда ученик записывается на урок, система ищет доступное время не по всем преподавателям, а только по рабочим часам подходящих учителей.
Про будущее проекта
Сейчас у ноукодеров TutGood две основные задачи на ближайшее время:
- Реализовать новый кастомный дизайн.
- Перенести базу клиентов и преподавателей с Airtable на PostgreSQL. Такое решение связано с ограничениями Airtable: у него есть лимит в 5 запросов в секунду и 50 тыс. записей в одной таблице, а для текущего этапа развития сервиса этого уже мало.
Так, постепенно разработчики начинают использовать решения на классическом коде для развития сервиса. Но это происходит поэтапно и только в тех областях, где действительно необходимо.
Связаться с Егором можно
в телеграме.
