Через 3 месяца после запуска у клиента все выглядело нормально: курсы открываются, сотрудники заходят, отчеты выгружаются. Потом началась знакомая картина - HR ведет прогресс в Excel, руководители не понимают, кто действительно прошел обязательные модули, партнеров обучают через почту и отдельные чаты. Формально LMS есть, по факту - еще один процесс, собранный вручную.
Я видел это в компаниях, где обучение уже влияет на продажи, аттестации и скорость вывода людей в работу. В этот момент выбирать нужно не по витрине функций. Смотрите на ручной труд, который останется после запуска.
Готовый сервис работает до тех пор, пока обучение не врастает в операционку
Если вам нужен онбординг, база курсов и простая сертификация, своя разработка чаще всего не нужна. Moodle 4.3, Teachbase, GetCourse и похожие сервисы обычно закрывают 70-80% потребности и позволяют проверить сценарий за 2-4 недели, без ранних затрат на 1,5-3 млн ₽.
Своя платформа начинает окупаться позже - когда доступ зависит от филиала, роли, статуса партнера, региона и срока сертификата, а данные нужно связать с HRM, CRM или ERP. Здесь у вас уже не просто обучение, а отдельный продукт с ролями, изоляцией данных и собственными правилами.
У нас был проект для партнерской сети в рознице с 120+ точками. На готовом сервисе франчайзи видели лишние курсы, обязательные модули назначались вручную, сертификаты собирали по таблицам. После перехода на кастомный портал на Laravel 11 + PostgreSQL 16 ручная работа координаторов сократилась примерно на 65% за 2 месяца.
Если обучение встроено в ежедневную работу бизнеса, LMS быстро перестает быть просто системой с курсами. Она становится частью операционной модели.
Для первого релиза хватает одного сценария
Самая частая ошибка - пытаться сразу собрать академию со всем набором: вебинары, мобильное приложение, магазин курсов, геймификацию, AI-помощника. Я бы строил первый релиз вокруг одного сценария: сотрудник проходит обязательный курс без участия HR, партнер получает сертификацию без переписки с координатором, клиент покупает и заканчивает программу без менеджера. Когда сценариев становится три, MVP обычно начинает расползаться.
Обычно в первом релизе достаточно такого набора:
- вход, роли и права доступа
- каталог курсов и личный кабинет
- тесты, прогресс, уведомления
- отчеты для руководителя
- админка для назначения программ
Для внутренней академии на Node.js 20 + NestJS + React мы выходили в прод за 11 недель. Один раз мы сами согласились заложить «все сразу» для обучающего центра и потеряли лишние 9 недель. Половина функций первым пользователям не понадобилась.
| Что включать | Первый релиз | Потом |
|---|---|---|
| Роли, курсы, тесты, прогресс | да | доработка |
| Отчеты и уведомления | да | расширение |
| Вебинары, сертификаты, white-label | да | |
| Мобильное приложение, магазин | 2-3 релиз |
Самые дорогие места в LMS скрыты не в курсах
Снаружи кажется, что вся сложность - в уроках и тестах. На практике деньги уходят в другое: кто создает пользователя, как назначается обучение, что происходит при переводе сотрудника, как закрывается доступ, куда уходит отчетность.
В одной внутренней LMS у нас 35% времени бэкенд-команды ушло на интеграции с HRM, корпоративным SSO и сервисом рассылок. Сам модуль курсов был прямолинейным. Если подрядчик начинает с экранов кабинета, это повод насторожиться. Сначала нужна карта ролей, событий и обмена данными.
До
- HR вручную создает пользователей
- программы назначаются письмами и таблицами
- прогресс собирают в Excel
После
- сотрудники приходят из HRM по API
- доступ выдается по роли и подразделению
- руководитель видит отставание в дашборде
На проекте сети филиалов срок включения сотрудника в обязательное обучение упал с 14 дней до 3 дней, а completion rate за квартал вырос с 52% до 81%.
Как понять, что вы уже строите SaaS, а не внутреннюю систему
Как только платформой пользуются несколько компаний, филиалов или клиентских кабинетов, меняется сам вопрос. Уже нужно решать, будет архитектура single-tenant или multi-tenant.
Single-tenant быстрее на старте и проще для одной компании. Multi-tenant имеет смысл закладывать сразу, если есть план продавать систему партнерам или внешним клиентам. В прошлом году мы переделывали внутреннюю академию, которую через полгода решили монетизировать. Пересборка модели данных и прав доступа обошлась почти в 2 раза дороже, чем стоила бы закладка multi-tenant в начале.
Здесь вопрос не в модности стека. Важно, выдержит ли он роли, изоляцию данных и рост нагрузки. Для таких задач мы чаще берем React или Next.js, на бэкенд - Node.js 20 + NestJS или FastAPI, дальше PostgreSQL 16, S3-совместимое хранилище и OAuth 2.0 или SAML для входа.
Нормальный старт - пилот и метрики на 12 недель
Рабочий порядок в 2026 году выглядит просто: короткий discovery, прототип, MVP, пилот на одной группе, потом масштабирование. Без пилота компании почти всегда платят за гипотезы, которые пользователям не нужны.
Я бы задавал подрядчику один вопрос: какие метрики вы будете улучшать в первые 12 недель после запуска. Если ответа нет, проект почти наверняка уйдет в обсуждение экранов и второстепенных функций.
Самая дорогая ошибка здесь - начинать строить платформу раньше, чем бизнес до нее дорос. У вас действительно проблема в LMS или в том, что ключевой процесс до сих пор держится на людях и таблицах?
