Low-code и no-code в 2026: что это, где реально работает и где предел

Отдел продаж полтора года не мог получить у IT-департамента бюджет на доработку CRM. Один из менеджеров за выходные собрал систему учёта заявок в конструкторе - без единой строчки кода. Через месяц эту самоделку уже сравнивают на планёрках с той самой CRM, которую всё это время нельзя было доработать.

Формально задача не изменилась. Изменилось то, кто её решает - и с какой скоростью.

Что такое low-code и в чём разница с no-code

No-code - подход, при котором приложение собирается целиком из готовых визуальных блоков: перетащил элемент, настроил условие, опубликовал. Кода нет вообще, и рассчитан такой инструмент на человека без технического образования - маркетолога, менеджера, бухгалтера.

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

На практике граница между ними размыта до полной неразличимости. Одна и та же платформа - скажем, Retool или отечественный SimpleOne - у одного пользователя работает в режиме no-code (собрал форму мышкой), а у другого в режиме low-code (дописал скрипт для нестандартной валидации). Продавцы платформ вообще склонны называть продукт и тем, и другим сразу - это маркетинговый ход, а не техническая классификация.

Людей, которые строят на этих платформах без формального ИТ-образования, называют citizen developers - гражданскими разработчиками. По оценкам аналитиков, к 2026 году они составляют порядка 80% пользователей low-code инструментов, против около 60% в 2021 году. Смещение понятное: чем проще инструмент, тем меньше повод звать программиста ради формы обратной связи или внутреннего трекера задач.

Почему про это вдруг заговорили все

Тут не обошлось без Gartner. Ещё в 2021 году аналитики компании спрогнозировали: к 2025 году 70% новых приложений, которые разрабатывают предприятия, будут построены на low-code или no-code технологиях - против менее 25% в 2020-м. Отдельные более поздние оценки сдвигают планку до 75% и переносят срок на 2026 год. Цифра красивая, часто цитируется вырванной из контекста - но касается она именно доли новых внутренних приложений компаний, а не всего программного обеспечения в мире вообще.

Причина спроса приземлённее любого прогноза - дефицит разработчиков. По разным оценкам Минцифры и отраслевых исследований, российскому рынку не хватает от 500 тысяч до миллиона IT-специалистов, особенно на позициях миддл и синьор. Backend-разработчиков и DevOps-инженеров ищут постоянно, и очередь на доработку внутренней CRM или системы согласования договоров у штатной команды разработки может растянуться на месяцы просто потому, что этим людям есть чем заняться помимо внутренних инструментов.

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

Где это реально работает

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

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

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

Автоматизация процессов. Связать CRM, почту, мессенджер и таблицу так, чтобы заявка с сайта сама попадала в CRM, а менеджеру приходило уведомление в Telegram - типовая задача для no-code сервисов интеграции. Мы разбирали похожие сценарии подробнее в материале про автоматизацию бизнес-процессов; там же счёт по эффекту от внедрения - без low-code эта категория задач тоже не была бы дешёвой.

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

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

Где начинается потолок

А вот дальше начинается менее приятная часть разговора, про которую продавцы платформ рассказывают неохотно.

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

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

Интеграции - третье. С популярными сервисами вроде CRM или почтовых рассылок готовый коннектор есть почти у любой платформы. А вот с внутренней ERP пятнадцатилетней давности, кастомным API поставщика или специфичным банковским протоколом коннектора не будет никогда - и тогда всё сводится к тому же самому коду, только написанному в чужой закрытой среде с ограничениями платформы, а не в родном стеке компании.

И главное - vendor lock-in, привязка к конкретному поставщику. Приложение живёт внутри экосистемы платформы, и перенести его логику на другой стек напрямую нельзя - только переписать с нуля, теряя время и часть функциональности. Риск не абстрактный: часть зарубежных сервисов ушла с российского рынка в 2022 году, и компании, построившие процессы на таких платформах, потеряли доступ к своим же данным и логике в одночасье. Тот случай, когда экономия на разработке в моменте оборачивается заложником на годы вперёд.

Есть ещё один пласт риска, о котором на старте почти никто не думает - управляемость. Когда десяток сотрудников без ИТ-бэкграунда самостоятельно собирают приложения для своих отделов, компания получает зоопарк несвязанных систем, за которые формально никто не отвечает. Gartner называет это проблемой governance для citizen development: автор приложения увольняется, а разбираться в логике, которую он собрал полтора года назад мышкой без единого комментария в коде, приходится тому, кто вообще не в курсе, что такая система существует. У обычной разработки для этого есть репозиторий, история коммитов и хотя бы формальный процесс код-ревью. У low-code инструмента, собранного в одиночку без контроля со стороны ИТ, - в лучшем случае экспорт в PDF с картинкой схемы.

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

Российские платформы и вопрос импортозамещения

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

В реестре зарегистрирован ряд отечественных low-code решений - в их числе ELMA365, ориентированная на автоматизацию бизнес-процессов и документооборота, SimpleOne с уклоном в ITSM и сервис-менеджмент, БПМСофт (бывший Terrasoft) с CRM- и BPM-функциональностью. У всех троих данные хранятся на серверах в РФ, что закрывает требование 152-ФЗ по локализации персональных данных без дополнительных костылей с трансграничной передачей.

Есть нюанс, который стоит понимать заранее: зрелость экосистемы у российских платформ пока не всегда дотягивает до мировых лидеров вроде Microsoft Power Apps или OutSystems - меньше готовых коннекторов, меньше сообщества, меньше туториалов на русском для нестандартных сценариев. За последние пару лет разрыв заметно сократился, но для сложных интеграций иногда приходится дописывать больше кастомного кода, чем закладывалось на старте проекта.

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

Когда нужен обычный код

Возвращаться к классической разработке стоит в нескольких случаях, и они довольно легко считываются ещё на этапе планирования.

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

А вы уже считали, во сколько обойдётся переезд с текущей low-code платформы, если она завтра поднимет тариф вдвое или откажется работать с российскими компаниями? Если ответа нет - это тоже сигнал, что пора хотя бы частично дублировать критичную логику вне закрытой экосистемы.

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