Low-code платформа простыми словами: когда на ней можно собрать внутреннюю систему, а когда нужна заказная разработка

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

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

Что такое low-code платформа простыми словами?

Это среда, в которой приложение собирают из готовых деталей: поле, таблица, форма, кнопка, шаг процесса, отчёт. Платформа сама хранит данные, раздаёт права и показывает экраны в браузере и на телефоне. Программист нужен там, где деталей не хватает.

Из чего обычно состоит такая система:

• Модель данных. Справочники и сущности: «Договор», «Контрагент», «Заявка» с полями и связями между ними.
• Формы и списки. Экраны для ввода и просмотра, фильтры, поиск, выгрузка в Excel.
• Процессы. Маршрут «создал → согласовал юрист → подписал директор» со сроками, напоминаниями и эскалацией.
• Роли и права. Кто видит какие записи и какие поля может менять.
• Интеграции. Коннекторы к почте, учётной системе, мессенджерам, плюс возможность вызвать чужой API.
• Скрипты. Вставки кода на языке платформы для расчётов и проверок, которые визуально не собрать.

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

Вариант	Кто собирает	Типичные задачи	Главное ограничение
No-code	Сотрудник без программирования: таблицы, формы, кнопки	Учёт заявок отдела, анкеты, простые справочники, личные трекеры	Логика — только та, что предусмотрел конструктор; данные и права примитивны
Low-code	Аналитик или разработчик платформы: визуальный редактор плюс вставки кода	Внутренние приложения с ролями, формами, отчётами и интеграциями	Всё, что не укладывается в модель платформы, пишется «в обход» и дорожает
BPM-система	Аналитик процессов, часто вместе с разработчиком	Маршруты согласования, заявки, договоры, поручения со сроками	Сильна в маршрутах, слабее в нестандартных экранах и тяжёлых расчётах
Заказная разработка	Команда разработчиков	Продукт под ваш процесс, клиентские кабинеты, сервисы с нагрузкой	Дольше на старте и дороже первая версия; нужен подрядчик или своя команда

Чем low-code отличается от no-code и BPM-системы?

No-code рассчитан на сотрудника без навыков программирования и ограничен тем, что предусмотрел конструктор. Low-code допускает код и сложнее в настройке. BPM-система — это класс продуктов вокруг маршрутов процессов; многие из них сами устроены как low-code платформы.

На практике границы размыты: продавцы называют один и тот же продукт и BPM, и low-code, и «платформой цифровизации». Полезнее смотреть не на ярлык, а на то, кто будет собирать систему и что случится, когда понадобится логика за пределами конструктора. Сравнение категорий — в таблице.

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

Какие бывают low-code платформы российских разработчиков?

Условно их четыре группы: BPM и системы электронного документооборота с конструктором процессов; конструкторы приложений внутри корпоративных порталов и CRM; no-code базы данных в виде «умных таблиц»; платформы для разработки бизнес-приложений с собственным языком.

Пример того, как устроено лицензирование, — страница цен ELMA365 на октябрь 2026 года: лицензируется число пользователей, именных или конкурентных; облако оплачивается подпиской на год, установка на свой сервер — разовой покупкой лицензий; в редакции Standard указан минимальный объём поставки — 20 лицензий, и она рассчитана на компании до 200 именных пользователей. Цифры и условия смотрите на официальной странице — для нас важна сама модель: стоимость растёт вместе с числом людей в системе.

Если вам нужна именно отечественная платформа — например, из-за требований к закупкам — проверьте продукт в Едином реестре российских программ. Его ведёт Минцифры по постановлению Правительства РФ от 16.11.2015 N 1236, а сам реестр открыт на reestr.digital.gov.ru. Сверьте название, правообладателя и номер записи.

Где low-code хорош: примеры задач

Платформа выигрывает там, где процесс типовой, пользователи — свои сотрудники, а главная ценность — быстро убрать таблицы и переписку. Систему на 3–5 сущностей с одним маршрутом согласования на ней реально собрать за недели, и менять её может аналитик, а не программист.

Примеры, где платформа обычно уместна:

• Согласование договоров и счетов. Маршрут из 3–4 шагов, сроки, напоминания, вложения, история решений.
• Заявки внутри компании. На пропуск, закупку, ремонт, доступы: форма, исполнитель, статус, отчёт по просрочкам.
• Контроль поручений. Поручение с автором, сроком и ответственным, еженедельная сводка руководителю.
• Справочники и реестры. Оборудование, контрагенты, доверенности, сертификаты с датой окончания и уведомлением.
• Кадровые мелочи. Заявления на отпуск, адаптация новичка по чек-листу, заявки на обучение.

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

Где low-code ломается?

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

• Сложная логика. Расчёт цены по десятку условий, план-фактор с пересчётом, распределение нагрузки. Визуальный редактор превращается в лабиринт блоков, а вставки кода живут без тестов и контроля версий.
• Нагрузка и объём. Сотни тысяч записей, отчёты в реальном времени, одновременная работа сотен людей. Платформа может это выдержать, но настройка производительности упирается в её архитектуру, а не в ваш код.
• Нестандартный интерфейс. Канбан с особыми правилами, план-схема, график с перетаскиванием, кабинет клиента в фирменном стиле — всё, что не входит в набор виджетов, пишется отдельно на языке платформы.
• Интеграции «в обе стороны». Готовый коннектор к учётной системе часто умеет простую выгрузку. Двусторонний обмен с обработкой ошибок, повторами и сверкой — уже работа программиста, только внутри чужой среды.
• Привязка к платформе. Данные можно выгрузить, логику — нет. Если правообладатель поменяет тарифы, условия облака или прекратит поддержку версии, варианты — платить или переписывать.
• Лицензии на пользователя. Пока в системе 15 сотрудников, это недорого. Когда туда нужно пустить 300 дилеров или клиентов, лицензии на внешний доступ становятся главной статьёй бюджета.
• Зависимость от одного настройщика. Систему знает один аналитик или интегратор. Уходит он — уходит и понимание, почему маршрут устроен именно так.

Сколько стоит владение за три года?

Считайте не цену старта, а сумму за три года: у платформы это лицензии на каждого пользователя за каждый год, внедрение и доработки у интегратора; у своей системы — разработка, поддержка и сервер. Сравнивать честно можно только при одинаковом объёме функций.

Формула для платформы: (число пользователей × годовая лицензия × 3) + внедрение + доработки + поддержка интегратора. Для установки на свой сервер вместо годовой подписки — разовая покупка лицензий плюс обслуживание сервера. Запросите у продавца именно эти цифры на ваше число пользователей и с запасом на рост — например, на 30 человек сейчас и 60 через два года.

Формула для своей системы на примере тарифов Roboweb: веб-приложение с кабинетами и ролями, базой данных и API, дашбордами, приёмом оплаты и 1–2 интеграциями — от 160 000 ₽ и от 10 дней по прайсу. Поддержка и развитие — от 7 900 ₽ в месяц, за 36 месяцев это от 284,4 тыс. рублей. Итого за три года — от 444,4 тыс. рублей, и в этой сумме нет платы за каждого пользователя: 20 их у вас или 200, лицензии не докупаются. Сервер оплачивается отдельно у хостинга.

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

Про права. В договорах Roboweb исключительное право на код остаётся у исполнителя, а заказчик получает лицензию на весь срок действия права: исходники в его репозитории, установка на любой сервер, доработка любыми подрядчиками. Данные, накопленные при работе системы, остаются за заказчиком.

Критерий	Скорее платформа	Скорее своя система
Пользователи	Сотрудники компании, 10–50 человек	Клиенты, дилеры, сотни внешних пользователей
Процесс	Типовой: заявка → согласование → исполнение	Нетиповой, с расчётами, правилами и исключениями
Срок жизни	Проверить идею за месяц-два	Годы работы, процесс — основа бизнеса
Интеграции	1–2 системы через готовые коннекторы	Учёт, склад, банк, сайт, обмен в обе стороны
Нагрузка и данные	Тысячи записей, отчёты раз в день	Сотни тысяч записей, отчёты в реальном времени
Лицензии	Число пользователей стабильно и невелико	Пользователей много, и их число растёт
Требования к хранению	Подходит облако платформы	Свой сервер, свои правила доступа и резервных копий

Как выбрать: платформа или своя система?

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

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

Что проверить в платформе до покупки?

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

1. Экспорт. Выгрузите тестовые записи вместе с вложениями, комментариями и историей статусов. Посмотрите формат: таблица, JSON, архив файлов.
2. API. Можно ли читать и писать записи извне, есть ли документация, лимиты на число запросов.
3. Лицензии. Цена именной и конкурентной лицензии, внешнего портала, минимальный объём покупки, условия при росте и сокращении числа пользователей.
4. Хранение. Облако продавца или свой сервер; где физически лежат данные — от этого зависят ваши обязанности по 152-ФЗ.
5. Версии. Как обновляется платформа, ломаются ли при обновлении ваши скрипты и кто их чинит.
6. Специалисты. Сколько интеграторов работает с платформой и можно ли сменить исполнителя без потери настроек.
7. Реестр. Если важно отечественное ПО — номер записи в реестре Минцифры.

Гибрид: прототип на low-code, потом своя система

Рабочая схема для спорных случаев: за несколько недель собрать процесс на платформе, прожить с ним два-три месяца, а когда станет ясно, какие шаги, поля и отчёты реально нужны, заказать свою систему по проверенному процессу. Прототип становится живым техническим заданием.

Чтобы переход прошёл без потерь:

• Сразу договоритесь о выгрузке. Ещё на старте убедитесь, что все записи и файлы можно выгрузить целиком, а не по одной.
• Записывайте правила. Каждый маршрут и каждую формулу — в отдельный документ: кто согласует, при каких условиях, в какой срок. Это и есть будущее ТЗ.
• Собирайте статистику. Сколько записей в месяц, какие отчёты открывают, где люди возвращаются к таблицам. По этим цифрам и решают, что войдёт в первую версию своей системы.
• Планируйте параллельную работу. Неделю-две обе системы живут вместе, данные сверяются, потом платформу переводят в режим только для чтения.

Как резать объём первой версии, мы подробно разбирали в статье «MVP или полная версия». Типичный повод для своей системы — служба заявок, которая выросла из простой формы. Например, ITSM-система «КРОМ» собрана кодом: 23 раздела от инцидентов до финансов ИТ, приоритет P1–P4 по матрице влияние × срочность, 4 канала приёма — портал, почта, Telegram и телефон. На уровне одной формы с маршрутом такое начинается легко, на уровне SLA, CMDB и отчётов — уже нет.

Когда low-code вам не нужен и какие ошибки делают?

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

Когда платформа лишняя:

• Пять человек и один список. Общая таблица с правами доступа справится, а заявки в неё может записывать бот; платить за лицензии рано.
• Есть готовая программа под задачу. Для продаж есть CRM, для учёта — учётные системы. Как выбирать между готовой системой и своей, мы разбирали в статье «своя CRM или готовая с доработками».
• Нужен клиентский продукт. Кабинет для клиентов, сервис по подписке, портал дилеров — это продукт с вашим интерфейсом и сотнями пользователей. Его разумнее делать как веб-приложение.

Частые ошибки:

• Выбор по демонстрации. На демо показывают типовой сценарий. Принесите продавцу свой самый неудобный случай и попросите собрать его при вас.
• Лицензии только на сегодня. Считайте бюджет на число пользователей через два-три года и на внешний доступ, если он может понадобиться.
• Скрипты без контроля. Вставки кода без описания и копий — первая причина, по которой систему никто не может поддерживать.
• Всё в одну платформу. Учёт, продажи, склад и кадры на одном конструкторе ради «единого окна». Каждая область по отдельности хуже, чем профильная система с интеграцией.
• Нет плана выхода. Ни разу не пробовали выгрузить данные целиком — узнаете о проблеме в момент, когда менять платформу уже срочно.

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

Короткие ответы на частые вопросы

Что такое low-code платформа простыми словами?

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

Чем BPM-система отличается от low-code?

BPM-система построена вокруг маршрута процесса: кто, в каком порядке и в какой срок согласует или исполняет задачу. Многие современные BPM-продукты сами являются low-code платформами, просто их сильная сторона — согласования и контроль сроков.

Можно ли потом перенести систему с low-code на свою разработку?

Данные — да, если платформа даёт полную выгрузку записей, файлов и истории. Логику и экраны не переносят: их заново проектируют и пишут, зато уже по проверенному в работе процессу.

Как проверить, что low-code платформа российская?

Найдите продукт в Едином реестре российских программ Минцифры на reestr.digital.gov.ru и сверьте название, правообладателя и номер записи. Слова «российская разработка» на сайте продавца реестровую запись не заменяют.

Сколько стоит своя внутренняя система вместо low-code?

В Roboweb веб-приложение с ролями, базой данных, API, дашбордами и 1–2 интеграциями стоит от 160 000 ₽ и делается от 10 дней, поддержка — от 7 900 ₽ в месяц. Точную смету считаем после брифа и фиксируем в договоре.

Услуги и кейсы по теме: веб-приложения и SaaS · кейс КРОМ · цены и сроки