Как мы для онлайн-школы выбирали между коробкой, конструктором и стройкой с нуля — и что из этого выходит по деньгам

Почти каждый разговор про EdTech-платформу начинается одинаково. «Мы хотим свою онлайн-школу. Сколько стоит и когда будет готово?» И вот тут я всегда беру паузу — не потому что не знаю, а потому что честный ответ звучит невежливо: «Зависит от того, что вы на самом деле собираетесь строить, а этого пока не знаете ни вы, ни я».

Привет, я Антон Фокин, CEO Qtim. Мы делаем образовательные платформы уже несколько лет — от школ на пару тысяч активных учеников до систем видеосвязи, которые заменили школе Zoom. И почти весь бюджет проекта решается не в момент, когда мы называем цифру, а раньше — на одной развилке, которую заказчики обычно проскакивают, не заметив. Про нее и расскажу. Заодно покажу, где смета в EdTech взрывается на пустом месте, а где, наоборот, можно не переплачивать.

Развилка, на которой решается всё

Представьте, что вы хотите открыть кафе. Можно купить франшизу, где всё придумано за вас. Можно взять помещение с готовой кухней и поставить своё меню. А можно запускать кафе с нуля: проектировать вентиляцию, закупать оборудование, выбирать посуду. Три разных бюджета, три разных срока, три разных уровня свободы. И ни один из вариантов не «правильный» — правильный тот, что подходит под вашу ситуацию.

С EdTech-платформой ровно то же самое, только развилку эту почти никто не проговаривает вслух. А зря — потому что именно она, а не выбор фреймворка и не дизайн кнопок, определяет и деньги, и сроки. У нас в практике три сценария, и я разберу каждый на реальном проекте.

Сценарий первый: не строить то, что уже построено

Есть соблазн считать, что «своя платформа» обязательно значит «написанная с нуля». Это дорогая иллюзия. Если базовая механика вашей школы стандартна — расписание, вебинары, тесты, — то строить под неё инфраструктуру заново примерно так же разумно, как отливать собственные кирпичи перед постройкой дома.

Для Mayak.study мы взяли готовое LMS-решение как фундамент. Не потому что поленились, а потому что ценность проекта была не в базе, а в надстройке: отчетность, онлайн-трансляции, пробные экзамены, контроль посещаемости, аналитика. Именно эти модули отличали Mayak.study от типовой онлайн-школы. Команда не потратила ни месяца на изобретение расписания — и вложила это время туда, где оно давало отдачу.

Плата за скорость — жесткость. Вы живёте в рамках чужой архитектуры, и когда захотите что-то, чего коробка не умеет, упритесь в стену. Но если ваши хотелки в эту стену пока не упираются — это самый быстрый и дешевый путь на рынок.

Перед выбором коробки стоит описать будущие сценарии школы: роли через полгода, нужные отчеты, правила проверки и коммуникации, которые придется менять без вендора. Если уже на этом этапе видны исключения, завязанные на обходные настройки и переписку с поддержкой, готовая LMS быстро начнет тормозить развитие. При стандартном ближайшем росте решение с надстройкой обычно дешевле и быстрее.

Сценарий второй: собрать разбросанное в одно

Другая частая история: у школы уже что-то работает, но живет по кусочкам. Один курс на одной платформе, второй — на другой, аналитика в третьем месте, а общей картины по ученику нет ни у кого.

С этим мы столкнулись на Studycats. Было шесть отдельных курсов — история, русский, обществознание, английский, литература, математика, — и каждый жил своей жизнью: свои ученики, своя аналитика, своё расписание. Для школы это значит, что ни один вопрос вида «сколько у нас всего активных учеников» или «где проседает вовлеченность» не имеет быстрого ответа — данные приходится сшивать вручную.

Мы собрали шесть курсов в одну платформу с общей базой пользователей и сквозной аналитикой. Сверху достроили то, что и делает её продуктом, а не просто складом уроков:

1. Единый вход и витрина курсов — ученик видит всё в одном кабинете, а не логинится в шесть разных мест.
2. Учебный контур — расписание, домашки с проверкой (автоматической, ручной и даже аудио — под разные типы заданий), пробные экзамены.
3. Механики удержания, подсмотренные у игр. Стрики, уровни, питомец-маскот, который растёт вместе с прогрессом. Интервальное повторение через карточки — чтобы пройденное не выветривалось. И внутренняя валюта, котокоины, которую можно получать за занятия и тратить, — на ней же построена реферальная программа: ученики приводят учеников.

Смысл всей этой геймификации не в «сделать помилее». Онлайн-обучение проваливается не там, где плохой контент, а там, где человек перестаёт заходить. Стрики и маскот дают повод вернуться сегодня, а не «когда-нибудь домучаю курс». Запустили к 1 сентября — специально к началу учебного года, — и на старте платформа держала больше тысячи учеников. Вся сборка заняла пять месяцев.

Это не стройка с нуля и не коробка, а промежуточный режим: вы связываете существующее в целое и достраиваете общий слой сверху. Дешевле полного цикла, гибче коробки — но требует, чтобы у вас уже было что связывать.

Сценарий третий: когда платформа и есть ваш продукт

И только теперь — тот самый полный цикл с нуля, ради которого обычно и приходят. Он оправдан, когда платформа не обслуживает бизнес, а сама им является: когда нагрузка, роли и логика уникальны, а конкурентное преимущество зашито именно в том, как всё устроено внутри.

Так мы делали Онлайн-Школу №1. Масштаб, ради которого вообще стоило городить полный цикл: 2 840 активных учеников за 30 дней, 24 предмета, 11 факультативов, отдельный поток подготовки к ЕГЭ. На таком объёме коробка и конструктор уже трещат по швам — и вот почему.

Учебное ядро мы собрали как веб-платформу на микросервисах: Node.js, NestJS, Nuxt.js, PostgreSQL, Redis, RabbitMQ. Сразу оговорюсь про частую путаницу — учебная часть живёт в вебе (расписание, ДЗ, материалы, мониторинг, коммуникация), а мобильные приложения закрывают узкие сценарии, а не дублируют платформу. Строить мобильную копию всего — это удвоить бюджет ради удобства, которое веб и так даёт.

Что этот выбор дал на практике:

Ролевая модель под рост. Восемнадцать ролей, и новая заводится за 15–20 минут. Звучит скучно, пока школа не начинает еженедельно придумывать новые типы сотрудников — кураторов, тьюторов, проверяющих. В коробке каждая такая роль превратилась бы в переписку с поддержкой вендора; у нас это движение на пару минут.

Автоматизация рутины. Около 80% проверок домашних заданий ушло в автомат, тестирование держит 14 типов вопросов. В переводе на человеческий — примерно 25 часов в неделю, которые преподаватели больше не тратят на ручную проверку.

И честно про обратную сторону, потому что микросервисы — это не бесплатный обед. Распределённая отладка, согласованность данных между сервисами, инфраструктура — всё это стоит времени команды. На маленьком проекте такая архитектура была бы дорогим украшением. Она отбивается там, где заложен рост. Онлайн-Школа №1 — ровно этот случай, и результат виден в цифрах: конверсия в оплату выросла с 12% до 27%, удержание — с 48% до 64%.

Раньше система школы жила в головах сотрудников — кто где что смотрит и как свести отчет. У куратора это была ссылка на Zoom в одном месте, чат — в другом, расписание — в гугл-таблице, а отчет по классу собирался вручную из трех источников. Любая нестыковка становилась личной проблемой конкретного человека: потерялась ссылка, разъехались цифры, кто-то забыл обновить таблицу. Теперь система живет в платформе, а не в чьей-то голове или переписке в чате. Отчет по классу — это не ручное сведение, а один экран, которому можно доверять. Вот в этом и есть разница между набором сервисов и продуктом: сервисы работают каждый сам по себе, а продукт держит в себе весь процесс школы целиком

Отдельная глава: когда дешевле построить свой Zoom, чем платить за чужой

Самое контринтуитивное решение на этом проекте — собственная видеосвязь вместо Zoom или Teams. На первый взгляд чистое переусложнение: готовые сервисы же есть, бери и подключай. Но давайте посмотрим не на технологию, а на то, как выглядит обычный будний вечер в онлайн-школе на чужом видеосервисе.

Ученик ищет ссылку на урок, потерявшуюся в чате две недели назад. Преподаватель отвечает на пятое сообщение «а урок сегодня здесь или где?». Куратор вручную сверяет, кто был на занятии, выгружая список из стороннего сервиса. Родитель просит запись, а её надо где-то отдельно найти и переслать. Ничего не сломалось — просто каждый вечер школа теряет по чуть-чуть времени и нервов на ровном месте.

Своя видеосвязь убирает этот вечер целиком. Ученик заходит на урок одной кнопкой из личного кабинета — без ссылок, паролей и «точно здесь?». Отвалился Wi-Fi или закрылась вкладка — нажал ту же кнопку, вернулся в ту же комнату. Посещаемость считается сама и сразу лежит в системе. Записи автоматически появляются у тех, кому положено — ученикам, кураторам, родителям. И, что для образовательного бизнеса в России стало уже операционным риском, а не гипотетическим, — никакой зависимости от зарубежных вендоров, которые могут в любой момент передумать.

Технически под капотом WebRTC и десктоп-приложение для учителя с демонстрацией экрана и управлением вниманием класса, но ученику всей этой кухни не видно — ему видна одна кнопка. Собрали за восемь месяцев, нагрузку массовых уроков держит стабильно, проект взял первое место в номинации «Цифровая трансформация». Готовый SDK был бы быстрее на старте — но тогда вход в урок принадлежал бы чужому продукту, с его экранами, лимитами и правилами, а не школе.

Так во что же это обходится

Теперь про деньги, ради которых вы, скорее всего, и открыли эту статью. Назвать цену EdTech-платформы «в среднем» так же осмысленно, как назвать среднюю стоимость дома: землянка и особняк формально оба дома. Но факторы, которые двигают смету, всегда одни и те же — и по ним вы сможете прикинуть свой случай ещё до разговора с любым подрядчиком.

Первый и главный — тот самый сценарий: коробка, конструктор или стройка с нуля. Разница между ними не в процентах, а в разах: коробка с надстройкой (как Mayak.study) и полный цикл под масштаб (как Онлайн-Школа №1) — это два разных финансовых мира, а сборка из фрагментов (Studycats) лежит где-то между. Это решение стоит принять осознанно, а не по инерции «хотим всё своё».

Дальше — число и сложность модулей. Расписание, домашки с автопроверкой, пробники, геймификация, аналитика, оплаты: каждый добавляет не только разработку, но и вечную поддержку. Сложность ролевой модели: чем тоньше права доступа, тем дороже логика — зато заложенная гибкость потом экономит. Собственная инфраструктура вроде видеосвязи или прокторинга — это отдельные подпроекты, оправданные, когда аренда упирается в риски, а не «чтобы было». И горизонт роста: платформа «на сейчас» и платформа «под трехкратный рост» — это два разных бюджета уже на старте, потому что закладываются в архитектуру с первого дня.

Чтобы не оставлять вас совсем без ориентиров, вот как это ложится в порядки величин:

1. Коробка с надстройкой — ориентировочно от 1,5 до 4 млн ₽. Самый предсказуемый бюджет: базу не пишем, платим за настройку и надстройку под вашу операционку.
2. Сборка из фрагментов — примерно 4–8 млн ₽. Зависит от того, сколько всего сшиваем и в каком состоянии то, что уже есть.
3. Полный цикл под масштаб — от 8–10 млн ₽ и вверх. Верхней границы, по сути, нет — она определяется тем, сколько модулей и какой рост вы закладываете; крупные платформы уходят и за 20 млн.

Сильнее всего смета растет на связности: ролях, интеграциях, правах доступа и данных. На встрече это звучит просто: подключим CRM, оплаты и аналитику. Потом выясняется, что у маркетинга одна логика сегментов, у методистов другая, у кураторов третья. Когда эти зависимости пропускают до старта, команда платит дважды: сначала за быстрый запуск, затем за миграцию, перенастройку ролей и пересборку связей между сервисами. Экономия на проектировании быстро превращается в отдельный бюджет на исправления.

И про сроки — та же история

«Когда будет готово» — вопрос-близнец вопроса про деньги, и ответ у него такой же честный и такой же неудобный: смотря что считать готовым. Первый работающий релиз и завершенная платформа — это разные горизонты, и путать их — верный способ разочароваться.

Реальные ориентиры из наших проектов:

1. Коробка с надстройкой — около полугода. Столько заняла Mayak.study: базовую инфраструктуру не строили, время ушло на отчётность, вебинары и пробники.
2. Сборка из фрагментов — порядка пяти месяцев. Studycats собрали ровно к 1 сентября, с жёстким дедлайном под учебный год.
3. Полный цикл, первый релиз ядра — от трёх месяцев. Именно за три мы подняли работающее ядро Онлайн-Школы №1. Но важная оговорка: это MVP, а не «вся платформа». Сотрудничаем с 2021 года, и всё это время она растёт итерациями.
4. Отдельная сложная подсистема (например, своя видеосвязь) — около восьми месяцев поверх основного проекта, потому что реальное время и нагрузка массовых уроков прощают меньше, чем обычный веб.

Отсюда простое правило планирования: закладывайтесь на то, что полный цикл стартует с MVP-ядра за несколько месяцев, а дальше живёт и достраивается. Образовательный продукт вообще редко бывает «доделан» — и это не баг, а нормальная его жизнь.

Что со всем этим делать

Если свести всё к одному совету, он будет не про технологии, а про порядок вопросов. Начинать не с «сколько стоит», а с двух других: насколько уникальна ваша учебная механика и на какой рост вы закладываетесь. Ответы на них определят сценарий, сценарий определит сроки и смету, а не наоборот. Заказчики, которые проходят эту развилку осознанно, почти никогда потом не переплачивают за переделки — а именно переделки, а не разработка, обычно и взрывают бюджет.

Если вы как раз стоите перед этой развилкой и не уверены, что выбрать — коробку, конструктор или полный цикл, — расскажите о задаче нашей команде. Разберём ваш сценарий и честно скажем, где не надо строить с нуля. В том числе если выяснится, что вам и правда хватит коробки — такое тоже бывает, и говорить об этом мы не стесняемся.