Решение «конструктор или код» принимается за час, если перестать спорить о сложности и померить восемь величин: размер сценария в узлах, число записей за прогон, размер файла, объём операций в месяц, требование ко времени ответа, необходимость отката всех шагов, требование к аудиту и частоту изменений логики. У каждой из восьми есть порог, за которым конструктор перестаёт быть дешёвым решением и становится дорогим. Ниже — эти пороги с числами и арифметикой, которую можно пересчитать на своих данных.
Второй результат такого замера обычно неожиданный: чистых случаев мало. В большинстве процессов часть шагов уверенно ложится в конструктор, а один-два узла упираются в порог. Правильный ответ здесь не «всё переписать», а гибрид: тонкий сценарий-оркестратор в конструкторе и небольшой собственный сервис на тяжёлую логику. На модельном процессе с потоком 100 000 операций в месяц гибрид обходится в 589 600 ₽ за три года против 648 400 ₽ у чистого конструктора и 762 000 ₽ у полностью собственной разработки.
Мы платформы не перепродаём и на подписках не зарабатываем, поэтому разбираем и обратную сторону: три статьи расходов, которые есть у low-code и которых нет в коде, и три статьи, которые есть только у кода. Отдельно — про тестируемость, откат и тот момент, когда парк сценариев перестаёт быть управляемым. Все цены и статусы платформ — по состоянию на сентябрь 2026 года.
Восемь критериев с порогами
Пороги ниже — не догма, а рабочие ориентиры, за которыми стоит одна общая логика: конструктор дёшев, пока прогон помещается в память, читается глазами и повторяется без последствий. Как только одно из трёх свойств теряется, цена владения растёт быстрее, чем экономия на разработке.
| Критерий | Измеримый порог | Конструктор уместен | Нужен код |
|---|---|---|---|
| Размер сценария | 25 узлов и 3 вложенных ветвления | Новый человек понимает схему за минуту, правку вносит владелец сценария | Схему невозможно прочитать без автора, каждая правка делается наугад |
| Записей за один прогон | 500 записей | Записи идут потоком, каждая обрабатывается независимо | Нужна постраничная обработка, хранение позиции и своя очередь |
| Размер данных за прогон | 15 МБ на файл | Файл проходит через узел целиком | Файл кладётся в хранилище, по процессу идёт ссылка, а не содержимое |
| Объём операций в месяц по одному сценарию | 121 000 операций | Оплата за операции дешевле разработки и сопровождения | Собственный сервис окупается за три года — расчёт ниже |
| Требование ко времени ответа | 30 секунд с гарантией | Очередь прогонов и ретраи допустимы, задержка ничего не ломает | Нужны явные гарантии, приоритеты и предсказуемая очередь |
| Транзакционность | Появление условия «все шаги или ни одного» | Шаги независимы, повтор безопасен по идемпотентному ключу | Нужен откат уже выполненных шагов — это транзакция в сервисе или в учётной системе |
| Требование к аудиту | Необходимость предъявить неизменяемый след проверяющему | Хватает истории прогонов на 30–90 дней | Нужен собственный журнал с регламентом хранения и защитой от правки |
| Частота изменений логики | 4 правки в месяц | Правок много: владелец меняет ветку за час, релиз не нужен | Правок мало, но они крупные: релизный цикл не мешает, а скорость конструктора не нужна |
Семь порогов из восьми при превышении толкают в сторону кода. Восьмой — наоборот: чем чаще меняется логика, тем сильнее выигрывает конструктор. Процесс, который правят по два раза в месяц, в коде стоит 24 задачи разработчику в год — это 336 000 ₽ при ставке 3 500 ₽/час и четырёх часах на изменение с релизом. В конструкторе те же правки вносит владелец сценария за час своего времени. Поэтому «переписать всё в код» проигрывает не на технике, а на скорости изменений в живом бизнесе.
Восемь горизонтальных шкал, одна под другой. У каждой слева зона «конструктор», справа зона «код», между ними отметка порога с числом: 25 узлов, 500 записей за прогон, 15 МБ на файл, 121 000 операций в месяц, 30 секунд гарантированного ответа, «все шаги или ни одного», «неизменяемый след для проверяющего», 4 правки логики в месяц. У последней шкалы зоны подписаны наоборот, и она выделена рамкой с подписью «критерий работает в обратную сторону». Подписи по-русски.
Как этим пользоваться на практике, видно на двух примерах. Первый: разбор входящей почты, 900 писем в месяц, двенадцать узлов, повтор безопасен по идентификатору письма, логика меняется каждый раз при появлении нового типа отправителя. Ни один порог не превышен, восьмой критерий прямо указывает на конструктор — решение принято, спорить не о чем. Второй: разнесение банковских платежей по счетам с частичными оплатами и объединёнными переводами. Записей за прогон немного, зато сразу три порога нарушены — транзакционность, аудит и нечитаемое ветвление. Здесь конструктор соберут за неделю, он даже заработает, а через квартал бухгалтерия обнаружит расхождение, которое никто не сможет объяснить, потому что повторить прогон на тех же данных уже нельзя.
Три статьи расходов low-code, которых нет в коде — и три наоборот
Спор о цене обычно заканчивается на смете запуска, где конструктор выигрывает всегда и с разгромным счётом. Смысл появляется, когда обе стороны раскладывают эксплуатацию. У каждого подхода есть по три статьи, которых у другого нет вовсе.
- Только у low-code: оплата за операции. Счёт растёт вместе с успехом — удвоился поток заявок, удвоилась строка расходов. В собственном сервисе обработка записи стоит долю копейки серверного времени, и рост потока на счёт почти не влияет.
- Только у low-code: часы внутреннего владельца сценариев. Тридцать сценариев съедают около 14 часов в месяц — правки, разбор сбоев, ответы коллегам «а почему не пришло». По внутренней ставке 1 100 ₽ это 184 800 ₽ в год, и в бюджете эта строка обычно не появляется вообще.
- Только у low-code: привязка к платформе. Переносимого формата сценария между площадками не существует. Переезд означает пересборку каждого сценария руками: в среднем 6 часов на сценарий, для парка из 30 штук — 180 часов и 630 000 ₽ по ставке подрядчика.
- Только у кода: цена первой версии. Один и тот же процесс — 49 000 ₽ сборки в конструкторе против 420 000 ₽ разработки сервиса. Разница в 8,5 раза оплачивается сразу, а окупается годами, если окупается вообще.
- Только у кода: зависимость от человека, который умеет его читать. Сценарий в конструкторе разберёт любой аккуратный сотрудник; сервис на незнакомом стеке — только разработчик. Уход одного человека превращается в риск для процесса, и снимается он документацией и код-ревью, то есть деньгами.
- Только у кода: собственный релизный контур. Тестовая среда, выкладка, мониторинг приложения, откат неудачного релиза — всё то, что в конструкторе идёт «в комплекте» и не требует отдельной сметы.
Столбчатая диаграмма из пяти статей годовой сметы, суммарно 889 200 ₽: доработки и новые ветки — 336 000 ₽, операции платформы — 216 000 ₽, часы внутреннего владельца — 184 800 ₽, подрядчик на сложные сбои — 126 000 ₽, потери от простоя — 26 400 ₽. Столбец «операции платформы» подписан «24 % сметы». Над диаграммой заголовок «Парк из 30 сценариев, 120 000 операций в месяц». Единицы — рубли в год, все значения подписаны.
Годовая смета парка: где на самом деле лежат деньги
Модельная компания: 60 человек, 30 действующих сценариев, 120 000 операций в месяц. Внутренний час сотрудника — 1 100 ₽ (оклад 120 000 ₽ со взносами на 160 рабочих часов), час инженера подрядчика — 3 500 ₽, модельная цена операции — 0,15 ₽ (по массовым тарифам российских платформ вилка укладывается в 0,10–0,25 ₽ и зависит от объёма).
Отсюда два практических вывода, которые меняют переговоры с подрядчиком. Первый: торговаться за тариф платформы почти бессмысленно — даже двукратная скидка на подписку снимает 12 % годовой сметы, тогда как отказ от шести необязательных доработок снимает вдвое больше. Второй: строка «часы внутреннего владельца» существует при любой архитектуре, и она не исчезает при переходе в код — там она просто переименовывается в задачи разработчику и дорожает втрое. Сравнивать конструктор с кодом надо по полной смете, а не по цене запуска. Методику, по которой мы приводим такие сметы к окупаемости и сроку возврата, мы описывали отдельно — она работает одинаково и для конструктора, и для собственной разработки.
Тестируемость и откат: аргумент, который перевешивает цену
Производительность конструктора обсуждают часто, тестируемость — почти никогда, хотя именно она определяет, сможете ли вы починить процесс на второй год. В коде повтор прогона — базовая операция: берём те же входные данные, запускаем в тестовом контуре, смотрим результат, правим, повторяем. В визуальном конструкторе этот цикл ломается в трёх местах.
- 1Нет отдельного контура. Правка чаще всего вносится в боевой сценарий, потому что копия сценария в том же аккаунте ходит в те же боевые системы: создаёт настоящие сделки и отправляет настоящие письма. На своём сервере это лечится вторым экземпляром платформы — он стоит только памяти; в облаке приходится либо заводить отдельные тестовые учётные записи во всех подключённых системах, либо править вживую.
- 2Нельзя повторить прогон на исходных данных. История прогонов показывает, что произошло, но подставить те же входные данные и пройти путь заново удаётся не всегда: часть данных уже изменена, часть внешних вызовов не идемпотентна. В итоге разбор сбоя превращается в реконструкцию по логам вместо воспроизведения.
- 3Нет полноценного отката. Конструктор откатывает версию схемы, но не последствия прогона: созданные сделки, отправленные письма, изменённые остатки. Компенсирующие действия проектируются вручную, и в 90 % сценариев их не проектируют вовсе.
Обходится это тремя приёмами, которые стоит закладывать с первого сценария, а не после первого инцидента. Первый — идемпотентный ключ у каждого сценария, который что-то создаёт: конкретное поле, по которому повтор распознаётся и завершается без действий. Второй — режим «сухого прогона»: сценарий проходит весь путь, но вместо записи в систему складывает результат в журнал, и его сверяют глазами. Третий — журнал обработанного на своей стороне, независимый от истории прогонов платформы, потому что срок хранения этой истории задаёт не ваш регламент, а тариф.
Схема из двух дорожек. Верхняя «Боевой контур»: триггер, узлы, запись в CRM и учёт. Нижняя «Тестовый контур»: тот же набор узлов, но конечные блоки заменены на «журнал сухого прогона» с пометкой «ничего не создаётся». Между дорожками вертикальные стрелки-сверки с подписью «сравнение результата». Слева от обеих дорожек общий блок «Идемпотентный ключ: поле, по которому распознаётся повтор». Справа блок «Собственный журнал обработанного» с подписью «срок хранения задаёте вы, а не тариф».
Гибрид: конструктор как оркестратор, сервис на тяжёлую логику
Гибридная схема выглядит так. Конструктор оставляет за собой то, что делает хорошо: слушает события, ходит в чужие системы за данными, маршрутизирует, уведомляет, ставит задачи. Всё, что упирается хотя бы в один порог, выносится в отдельный небольшой сервис: расчёт, разбор документа, массовая выгрузка, транзакционная операция. Сценарий вызывает этот сервис как обычный внешний адрес и получает готовый ответ.
Выигрыш тут не только в производительности. Во-первых, тяжёлые шаги перестают тарифицироваться: разбор документа из пятидесяти строк — это один вызов сервиса, а не пятьдесят операций платформы. В нашей модели доля шагов, остающихся в конструкторе, падает примерно до 20 %, и вместе с ней падает счёт. Во-вторых, самая сложная часть логики получает нормальные тесты, версии и откат, а самая изменчивая часть остаётся там, где правка занимает час. В-третьих, сервис получается маленьким: 180 000 ₽ разработки против 420 000 ₽ за полную замену процесса кодом, потому что интеграции, авторизации и маршрутизация остаются на конструкторе.
Карта из двух зон, разделённых пунктиром с подписью «граница ответственности». Левая зона «Конструктор — оркестратор»: узлы «событие», «получить данные из CRM», «получить данные из 1С», «маршрут», «уведомление», «постановка задачи», подпись «20 % шагов остаются тарифицируемыми». Правая зона «Собственный сервис»: блоки «разбор документа», «расчёт», «транзакционная запись», подпись «180 000 ₽ разработки, тесты и откат». Между зонами двусторонняя стрелка с подписью «контракт: список полей и коды ответа». Внизу отдельная стрелка «сервис недоступен → сценарий копит в очередь».
Числа выше зависят от объёма, поэтому полезнее держать в голове не сумму, а формулу и две точки переключения. Расходы конструктора за три года равны 108 400 ₽ плюс 5,4 ₽ на каждую операцию месячного потока. Расходы гибрида — 481 600 ₽ плюс 1,08 ₽ на операцию, потому что в тарификации остаётся пятая часть шагов. Расходы полностью собственного сервиса — 762 000 ₽ почти независимо от объёма. Приравняйте попарно и получите пороги: 86 000 и 260 000 операций в месяц.
| Поток по процессу | Дешевле всего за 36 месяцев | Почему |
|---|---|---|
| До 86 000 операций в месяц | Чистый конструктор — 108 400 ₽ плюс 5,4 ₽ за операцию | Разработка сервиса не окупается: инженерные часы дороже, чем оплата операций |
| 86 000 – 260 000 операций в месяц | Гибрид — 481 600 ₽ плюс 1,08 ₽ за операцию | Тяжёлые шаги уходят из тарификации, изменчивая часть остаётся дешёвой в правках |
| Свыше 260 000 операций в месяц | Собственный сервис — 762 000 ₽ | Оплата за операции обгоняет стоимость разработки и сопровождения |
График. Ось X — операций в месяц по процессу, от 0 до 300 000. Ось Y — расходы за 36 месяцев в рублях. Три линии: «конструктор» из точки 108 400 ₽ с наклоном 5,4 ₽ за операцию, «гибрид» из точки 481 600 ₽ с наклоном 1,08 ₽, горизонталь «собственный сервис» на 762 000 ₽. Отмечены две точки пересечения: 86 000 и 260 000 операций в месяц. Полоса между ними залита и подписана «зона гибрида». Отдельной меткой на оси X — 100 000 операций с тремя значениями: 648 400 ₽, 589 600 ₽, 762 000 ₽.
Платформы по инженерным критериям
Если решение склонилось к конструктору, остаётся выбрать площадку. Почти все сравнения интеграционных платформ в выдаче написаны их же партнёрами, поэтому сравниваем по критериям, которые всплывают на втором году эксплуатации, а не на демонстрации. Тарифы, лимиты и списки коннекторов меняются — проверяйте их на дату решения, а таблицей пользуйтесь как набором вопросов, которые надо задать до подписания договора.
| Инженерный критерий | n8n на своём сервере | Albato | ApiX-Drive | Nodul |
|---|---|---|---|---|
| Отдельный тестовый контур | Второй экземпляр на том же сервере, стоит только памяти | Уточняйте наличие отдельного окружения: типовая практика — копия сценария в том же аккаунте | Уточняйте наличие отдельного окружения | Уточняйте наличие отдельного окружения |
| Повтор прогона на исходных данных | Прогон повторяется из истории, входные данные подменяются в узле | Ручной перезапуск есть, подмена входных данных ограничена — проверяйте на демонстрации | Ручной перезапуск есть, подмена входных данных ограничена | Ручной перезапуск есть, подмена входных данных ограничена |
| Версионирование и откат схемы | Выгрузка в файл, хранение в репозитории, откат к любой версии | Проверяйте полноту экспорта: без него единственная версия — текущая | Проверяйте полноту экспорта | Проверяйте полноту экспорта |
| Срок хранения истории прогонов | Задаёте сами, ограничение только дисковое | Ограничен тарифом — уточняйте срок и что именно остаётся в теле запроса | Ограничен тарифом | Ограничен тарифом |
| Потолок по объёму | Упирается в сервер, лечится ростом машины и очередью | Тарифный план по операциям: счёт растёт линейно | Тариф по связям и объёму: рост ступенями | Тарифная сетка платформы |
| Юридический слой | Данные не покидают контур, поручение обработки нужно только администратору | Юрлицо и серверы в РФ, соответствие ч. 5 ст. 18 152-ФЗ | В реестре Минцифры — существенно для госзаказчика | Российская разработка, договор в рублях |
| Зрелость и коннекторы к российскому стеку | Коннекторы к 1С, Битрикс24 и amoCRM пишутся через HTTP-узел, это часы на каждую связку | Широкий набор готовых коннекторов — основное преимущество | Упор на простые связки «система А → система Б» | Моложе аналогов, сильные ИИ-узлы: наличие нужного коннектора проверяйте до договора |
Ограничения, о которых в вендорских материалах не пишут, стоит проговорить прямо. У n8n на своём сервере их три: нужен администратор и дежурство, обновления и их совместимость со сценариями — ваша забота, готовых коннекторов к российскому стеку почти нет. У любой облачной платформы ограничение общее: через неё проходят персональные данные ваших клиентов, а значит нужен договор, поручение обработки и понимание срока хранения логов прогонов. Второе общее — переносимого формата сценария не существует, и уход с платформы стоит пересборки парка. Третье — глубина логики: там, где на своём сервере пишется двадцать строк кода, в облачном конструкторе придётся собрать десяток узлов или отказаться от задачи. Ни одно из этих ограничений не является поводом не пользоваться платформой; поводом является только то, что о них узнают через год.
Таблица-сравнение: четыре колонки-платформы (n8n на своём сервере, Albato, ApiX-Drive, Nodul) и семь строк-критериев: тестовый контур, повтор прогона, версионирование и откат, срок хранения истории, потолок по объёму, юридический слой, зрелость и коннекторы. Клетки заполнены короткими пометками, у неопределённых стоит знак вопроса с подписью «спросить на демонстрации». В колонке n8n отдельно выделено «данные не покидают контур», в колонке ApiX-Drive — «реестр Минцифры». Все подписи по-русски.
Тридцать сценариев и вопрос про владельца
Есть девятый критерий, которого нет в таблице, потому что он не про технику. Конструктор предполагает, что в компании есть человек, который держит парк сценариев в голове и в порядке. Пока сценариев пять, эту роль исполняет любой толковый сотрудник в свободное время. На тридцати она превращается в 14 часов в месяц, и в этот момент выясняется, что должности такой нет, в KPI это не входит, а в отпуск человек всё-таки уходит.
Клубок из сценариев узнаётся по шести признакам: два сценария делают почти одно и то же, но чуть по-разному; есть сценарии, назначение которых никто не помнит; кто-то раз в неделю перезапускает прогон руками; клиенты получают письма от отправителя, которого нет ни в одной рассылке; никто не берётся оценить последствия отключения любого узла; правка вносится сразу в боевой контур. В гибридной схеме к этому добавляется седьмой признак и он опаснее прочих: логика расползается по обе стороны границы, и один и тот же расчёт оказывается сделан и в сценарии, и в сервисе — по-разному. Лечится это дёшево: карта запусков на одном листе, владелец у каждого сценария, правило именования, карантин на 30 дней для всего, чьё назначение не смог объяснить ни один сотрудник, и записанный контракт между конструктором и сервисом. Час на карту окупается на первом же инциденте.
Матрица решений: десять типовых задач
Ниже — десять задач, которые встречаются почти в каждой компании, с рекомендацией по каждой. Это не универсальный ответ, а иллюстрация того, как восемь порогов работают на живых примерах: обратите внимание, что решение меняется не от названия задачи, а от объёма и обратимости.
| Задача | Объём | Рекомендация | Решающий критерий |
|---|---|---|---|
| Приём заявок с сайта и из почты в CRM | 900 в месяц | Конструктор | Повтор безопасен, логика меняется часто |
| Синхронизация остатков 1С и сайта | каждые 15 минут | Конструктор, но по событию, а не опросом | Логика тривиальна, дорого только число операций |
| Расчёт скидки по двенадцати условиям | при каждом заказе | Учётная система или сервис | Ветвление не читается и не тестируется |
| Разнесение платежей по счетам с частичными оплатами | 400 в месяц | Сервис или доработка учёта | Нужны транзакция и доказуемый след |
| Уведомления и эскалации сотрудникам | 3 600 в месяц | Конструктор | Дешёвая ошибка, простая проверка результата |
| Выгрузка каталога на 40 000 позиций | еженедельно | Сервис | Больше 500 записей за прогон |
| Распознавание накладных и занос в учёт | 600 в месяц | Гибрид | Распознавание — сервис, маршрут и уведомления — конструктор |
| Ежедневная отчётность руководителю | 30 прогонов в месяц | Конструктор | Расписание — самый предсказуемый триггер |
| Отправка платёжных поручений в банк | 120 в месяц | Код и обязательное подтверждение человеком | Нет права на дубль и на потерю |
| Классификация обращений языковой моделью | 4 000 в месяц | Гибрид с проверкой результата | Ответ недетерминирован, нужен порог уверенности и передача человеку |
Четыре строки этой таблицы у нас собраны в готовые решения каталога — разбор входящей почты, распределение заявок между менеджерами, распознавание накладных и автоматическая сверка документов. В каждом сторона границы уже выбрана и обоснована, а в поставку входит то, что при самостоятельной сборке забывают: идемпотентный ключ, журнал обработанного, очередь необработанного и порядок приёмки. Смотреть их имеет смысл до того, как вы начнёте проектировать своё, — хотя бы чтобы сверить состав работ.
Схема-поле по двум осям: горизонтальная «объём за прогон» от единиц до десятков тысяч записей, вертикальная «обратимость операции» от «повтор безопасен» до «повтор недопустим». Поле разделено на три зоны: «конструктор» (левый нижний угол), «гибрид» (середина), «код» (правый верхний угол). На поле расставлены десять точек-задач с короткими подписями: приём заявок, синхронизация остатков, расчёт скидки, разнесение платежей, уведомления, выгрузка каталога, распознавание накладных, отчётность, платёжные поручения, классификация обращений. Границы зон подписаны «500 записей» и «нужна транзакция».
Как сформулировать задание подрядчику, если решение гибридное
Гибрид ломается не на технике, а на размытой ответственности: сценарий ждёт от сервиса одного, сервис отдаёт другое, и виноватого нет. Семь пунктов в задании закрывают почти все споры.
- 1Явно перечислите, что живёт в сценарии и что в сервисе. Не «интеграция с 1С», а список: маршрутизация, уведомления и постановка задач — в сценарии; разбор документа и расчёт — в сервисе.
- 2Опишите контракт между ними как список полей и кодов ответа, а не словами. Что сервис принимает, что возвращает, какой код означает «повтори позже», а какой — «эту запись обрабатывать не надо».
- 3Назовите идемпотентный ключ конкретным полем. Это одна строка в задании, которая экономит месяцы разбора дублей.
- 4Задайте пороги приёмки в числах: сколько записей за прогон, за какое время сервис обязан ответить, какая доля ошибок допустима и что происходит с остатком.
- 5Отдельно опишите поведение при недоступности сервиса: сценарий встаёт, копит записи в очередь или пропускает их. У этих трёх реакций разные последствия для бизнеса, и выбирать должен заказчик, а не разработчик.
- 6Зафиксируйте, кто владеет сценарием после сдачи и на каком основании вы можете менять его без подрядчика. Право на правку без согласования — это пункт договора, а не добрая воля.
- 7Пропишите состав передачи: выгрузка сценариев в ваш репозиторий, исходники сервиса, доступы и ключи API на ваших учётных записях, паспорт каждого сценария на полстраницы.
Эти же семь пунктов работают как фильтр подрядчиков. Исполнитель, который спокойно принимает пункт про право на самостоятельную правку и передачу исходников, рассчитывает зарабатывать на развитии. Исполнитель, который начинает объяснять, почему выгрузка сценариев «технически невозможна», рассчитывает зарабатывать на вашей несвободе. Что должно быть в договоре на разработку помимо этого, мы разбирали отдельно.
Когда low-code не подходит категорически
Мы зарабатываем в том числе на сборке сценариев, поэтому этот список стоит читать внимательнее остальных. В шести ситуациях конструктор не «чуть хуже», а неприменим, и мы отговариваем от него независимо от бюджета заказчика.
- Необратимые операции без участия человека: платёжные поручения, списания со склада с материальной ответственностью, юридически значимые действия. Конструктор выполняет шаги по очереди и не умеет откатывать уже сделанное — значит, любой сбой в середине оставляет систему в состоянии, которого нет ни в одном регламенте.
- Требование доказуемого следа. Если проверяющему надо предъявить, кто, когда и на каком основании изменил запись, и доказать, что журнал не редактировали, история прогонов конструктора для этого не годится: она хранится ограниченный срок и не проектировалась как доказательство.
- Отраслевое регулирование с требованиями к среде. Там, где закреплён состав программного обеспечения и режим доступа, добавление в контур внешней платформы означает пересмотр всей аттестации. Дешевле сразу проектировать внутри разрешённого периметра.
- Персональные данные особых категорий: сведения о здоровье, биометрия, паспортные данные в теле запроса. Через облачный конструктор такие поля не пропускают вообще — передают ссылку на защищённое хранилище, а сопоставление делают в своём контуре.
- Жёсткий SLA на отдельную операцию. Очередь прогонов, ретраи и перезапуск платформы после обновления дают непредсказуемые задержки. Если задержка в 30 секунд означает штраф или потерянную сделку, нужны явные гарантии времени ответа, а их даёт только собственный контур.
- Некому быть владельцем сценариев. Если в компании нет человека, готового тратить на парк 14 часов в месяц, и нет денег на подрядчика с поддержкой, конструктор проживёт до первой смены прайса или первого ушедшего сотрудника. Здесь честный ответ — не автоматизировать пока вовсе или взять готовое коробочное решение с чужой поддержкой.
Обратите внимание: пять причин из шести — не технические. Конструктор проигрывает не потому, что медленный, а потому, что не даёт доказуемости, обратимости и предсказуемости. Там, где эти три свойства обязательны, дискуссия о цене запуска не имеет смысла, и правильный ответ один из трёх: писать сервис, дорабатывать учётную систему штатными средствами или оставлять шаг человеку. Последний вариант обсуждают реже всего, а он часто выигрывает: операция, которая случается четыре раза в месяц и требует решения, дешевле в исполнении сотрудника, чем в поддержке сценария, который это решение имитирует.
Таблица-сравнение из шести строк в две колонки. Слева стоп-сигнал: необратимые операции без человека, требование доказуемого следа, отраслевое регулирование среды, персональные данные особых категорий, жёсткий SLA на операцию, некому быть владельцем сценариев. Справа рекомендация: транзакция в сервисе или учётной системе, собственный журнал с регламентом хранения, проектирование внутри разрешённого периметра, ссылка вместо содержимого, собственный контур с гарантией времени ответа, коробочное решение с чужой поддержкой или отказ от автоматизации. Внизу подпись: «пять причин из шести — не про технику».
Граница между конструктором и кодом проходит там, где вы перестаёте уметь доказать, что система сработала правильно.
