Low-code или custom-разработка: как выбрать без переплаты и технического долга

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

Вопрос low-code или custom-разработка часто обсуждают как битву «дёшево против качественно», но это ошибочная рамка. Low-code — не дешёвая замена программистов, а custom — не обязательно многолетний проект на миллионы. Это разные инструменты, и выбор зависит от того, насколько процесс критичен, какие нужны интеграции и как он изменится через год-два. Разберём выбор на трёх типовых задачах.

Коротко о категориях

Low-code платформа позволяет строить интерфейсы и процессы из готовых компонентов, визуальных схем и коннекторов. Код пишут лишь там, где стандартных возможностей не хватает: Microsoft Power Apps, Retool, OutSystems, Mendix, а для автоматизации процессов — n8n, Make или Zapier.

No-code платформы вроде Bubble, Glide или Airtable ориентированы на людей без навыков программирования. Граница между категориями размыта: любое серьёзное решение, даже собранное мышкой, всё равно требует технического специалиста для архитектуры, безопасности и интеграций.

Задача 1. Кабинет партнёров на 300 дилеров

Партнёры должны видеть свои цены, остатки, историю заказов и документы. Данные лежат в ERP, доступ нужен снаружи, каждый видит только себя.

Low-code здесь закрывает интерфейс и авторизацию за несколько недель, но быстро упирается в две вещи: лицензирование за каждого внешнего пользователя и ограничения на количество запросов к ERP. Для 300 партнёров стоимость платформы может превысить стоимость разработки уже на второй год.

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

Задача 2. Согласование заявок внутри компании

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

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

Задача 3. Конфигуратор продукта с собственной логикой цен

Клиент выбирает параметры, система считает цену по сложным правилам, проверяет совместимость и резервирует материалы. Это уже конкурентное преимущество компании.

Здесь custom-разработка оправдана: логику трудно выразить визуальными блоками, нагрузка неравномерная, а держать ядро бизнеса на чужой платформе рискованно. То же касается случаев, когда персональные данные клиентов нельзя хранить у стороннего поставщика или интерфейс должен быть уникальным.

Сравнение подходов

Как посчитать стоимость честно

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

Для custom в ту же таблицу идут разработка, хостинг, тестирование, мониторинг и развитие. Часто оказывается, что на горизонте одного года дешевле low-code, а на горизонте трёх — уже custom. Именно поэтому решение принимают по TCO, а не по цене запуска.

Проверка платформы до старта

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

Microsoft в рекомендациях для Power Platform отдельно подчёркивает роли администраторов, разделение сред, безопасность и мониторинг. Эти правила не замедляют работу, но спасают от хаоса через год.

Гибрид — чаще всего правильный ответ

Low-code и custom не обязательно противопоставлять. Распространённая модель: критическая бизнес-логика и данные живут в собственном backend, а внутренняя админпанель или отчётность собирается на low-code поверх него через API. Другой сценарий — MVP на платформе проверяет гипотезу, после чего самая ценная часть переносится в custom-продукт.

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

Пять вопросов перед решением

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

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

Частые вопросы

Можно ли перенести систему с low-code в custom позже?

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

Low-code — это безопасно?

Крупные платформы хорошо защищают инфраструктуру. Риски возникают не из-за платформы, а из-за неконтролируемых прав доступа, публичных ссылок и отсутствия журнала действий.

Что дешевле на горизонте трёх лет?

Для внутреннего инструмента на несколько десятков пользователей обычно low-code. Для системы с сотнями внешних пользователей, сложными интеграциями или высокой нагрузкой часто выгоднее custom.

Сколько длится MVP на low-code?

Типовой внутренний инструмент — от двух до шести недель вместе с интеграциями. Главное — заранее договориться, по каким критериям вы признаете гипотезу подтверждённой.

Если процесс типовой и нужно быстро проверить ценность, low-code может быть лучшим стартом. Если система определяет продукт, имеет сложные интеграции или высокие риски, собственная архитектура даёт больше контроля. GL.ua может провести discovery, собрать прототип и помочь выбрать подход без привязки к одному инструменту — подробнее о наших услугах по разработке сайтов и систем.