No-code vs кастомная разработка: где ловушка масштабирования
Собрали CRM на No-code за две недели. Команда довольна.
Через полгода: 80 менеджеров, интеграция с 1С через CSV по пятницам, лимиты API и лицензии ×4. Бизнес растёт — платформа нет.
Проблема не в No-code как инструменте. Проблема в том, что конструктор принимают за систему на годы, а не за быстрый старт.
Три этапа ловушки масштабирования: 1. Старт — 5–15 человек, «за две недели вместо полугода» 2. Рост — 30–80 пользователей, обходные Excel и платные модули 3. Стена — 100+ мест, 1С/ERP, филиалы, пик. Платформа либо не умеет, либо умеет за enterprise-тариф
Ориентир по экономике на 3 года: No-code: от десятков тысяч ₽/мес → часто 300–800+ тыс. ₽/мес при росте мест. Только лицензии за 3 года нередко 3–10+ млн ₽. Кастомный MVP узкого контура: обычно 1,5–3 млн ₽ на запуск + поддержка. Перелом: когда 24–36 месяцев лицензий ≈ бюджет кастома и платформа уже режет процесс.
Когда No-code уместен: типовой процесс, маленький пилот, минимальные интеграции, заранее зафиксированный критерий ухода. Когда сразу кастом: уникальные процессы, глубокая связка с 1С/ERP, рост нагрузки, права на код и независимость от вендора.
Полный разбор с TCO и чеклистом ухода: https://ninelab.ru/blog/nocode-vs-custom?utm_source=setka&utm_medium=social&utm_campaign=ninelab_setka_nocode_vs_custom
У вас No-code сейчас как временный старт или уже как основная система на годы?
· 22.07
Да, ловушка обычно не в no-code как таковом, а в том, что scaling cost появляется позже и незаметно. Я бы заранее смотрел на интеграции, ownership данных и возможность вытащить бизнес-логику без переписывания всего с нуля. У вас это уже упиралось в 1С или лимиты API?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 22.07
Да, сама по себе no-code ломается редко. Проблема почти всегда в экономике или в управляемости: растёт стоимость лицензий, бизнес-логика размазывается по автоматизациям - и это потом плохо экспортируется.
Мы упирались в оба случая: интеграция фактически превращалась в ручной обмен CSV, плюс не хватало квот API на выросшее число пользователей.
Отдельно - перенос бизнес-логики процессов. Данные выгрузить несложно, а сценарии уже проблема. В итоге миграция становится похожа на «написать с нуля».
Поэтому критерии ухода лучше фиксировать заранее: число пользователей, лицензии, обязательные интеграции с другими системами.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён