Спор «Tilda / Bubble / таблица с кнопками» против «напишем систему» редко бывает про технологии. Это спор про срок жизни продукта, уникальность правил и то, кто будет это сопровождать. Заказчик слышит «no-code — быстро и дёшево», разработчик слышит «потом это нельзя нормально сдать и развивать», агентство клиента хочет закрыть проект в этом квартале. Все правы локально и ошибаются глобально, если не назвали критерии.
Проблема в ложной развилке. Рынок продаёт крайности: «конструктор за неделю заменит отдел разработки» и «только кастом, иначе несерьёзно». На деле большинство компаний живут в гибриде: витрина на конструкторе, учёт в облачной CRM, кусок уникальной логики в заказе. Ломается не стек. Ломается обещание, что выбранный путь вечный.
Статья для заказчика, внутренней разработки и компании, которая собирает решения клиентам. Ниже — зачем выбирать осознанно, как решить, нужно ли вам заказывать код, с чего начать пилот и когда no-code вреден — так же как вреден кастом «для статуса». Связанный вопрос первой версии — зачем нужен MVP.
Зачем этот выбор вообще важен
No-code и low-code ускоряют сборку стандартных экранов: лендинг, форма, простая воронка, каталог без сложной логики, внутренний трекер на готовых блоках. Вы платите подпиской и ограничениями платформы: лимиты, чужой аптайм, чужие правила данных, сложный вывоз, если решите уйти.
Заказная разработка нужна, когда правила ваши, интеграций много, нагрузка и права не укладываются в шаблон, продукт и есть бизнес, а не приложение к бизнесу. Вы платите временем и командой, зато владеете кодом, можете менять поведение точечно и не зависите от тарифа «модуль X отключили».
Для разработчика честный совет клиенту иногда звучит «вам хватит конструктора» — это не потеря контракта, а экономия репутации. Для заказчика — понимание total cost: дешёвый старт no-code плюс год костылей может обогнать аккуратный кастом узкого контура. Для компании-интегратора — прозрачность: что останется клиенту, если вы завтра не на связи. Экспорт, доступы, документация процесса важнее логотипа платформы.
Зачем выбирать письменно: через полгода вы забудете, почему взяли конструктор. Критерии на одной странице спасают от священной войны «надо всё переписать» без фактов.
Что обычно быстрее на no-code
- Посадочные, события, промо, простые многостраничники.
- Сбор заявок и связка с почтой / мессенджером / облачной CRM.
- Внутренние учётки на десятки записей в день без жёсткого SLA.
- Прототип для проверки оффера, пока спрос не доказан.
Нужна ли заказная разработка именно вам
Скорее да, если продукт — ядро выручки: кабинет клиента, биллинг, сложные роли, очередь работ, расчёт, который нельзя отдать «примерно». Если 152-ФЗ, доступы, журнал, контур, который не должен лежать на чужом аккаунте без договора. Если интеграции с 1С, банком, отраслевой системой, и готовые коннекторы врут или их нет.
Скорее нет как первый шаг, если вы проверяете гипотезу, страниц мало, логика стандартная, команда не готова сопровождать код, бюджет на три месяца а не на продукт. Тогда конструктор или облачный сервис честнее. Кастом «на всякий случай, вдруг взлетим» часто не взлетает, потому что первая версия слишком тяжёлая, см. разработку MVP.
Нужен ли гибрид: часто да. Сайт-витрина на конструкторе или шаблоне, заявки в CRM, уникальный расчёт или кабинет — отдельно. Не тащите интернет-магазин с акциями и остатками в инструмент для лендингов. Не тащите корпоративный сайт в тяжёлый фреймворк, если править будут маркетологи раз в месяц.
Для SaaS-задумки смотрите разработку SaaS: подписки, тенанты, биллинг на no-code быстро упираются. Для витрины — разработка сайтов или конструктор. Для внутренних правил — разработка ПО.
Семь вопросов на решение
- Это витрина, внутренний учёт или продукт, который продаёте клиентам?
- Правила стандартные или «у нас не как в коробке»?
- Кто будет менять логику через полгода: маркетолог, аналитик, разработчик?
- Что будет при x10 нагрузке и x10 записей?
- Можно ли выгрузить данные и уйти с платформы за неделю?
- Есть ли критичные интеграции без нормального коннектора?
- Готовы ли вы к подписке платформы как к постоянному COGS?
Как выбрать и с чего начать
Начните с объекта и сценария, не с каталога платформ. «Заявка → квалификация → счёт» на бумаге. Затем спросите: это уже умеет готовый сервис на 80%? Если да — берите сервис, доработайте поля и регламент. Если нет — сузьте кастом до этого зазора, остальное не переизобретайте.
Сделайте пилот на одном сценарии в выбранном инструменте за 2–4 недели. Критерий: пользователь (менеджер или клиент) проходит путь без созвона с вами. Если на второй неделе вы уже пишете JavaScript-костыли в «безкодовой» среде и обходите лимиты — это сигнал, что инструмент не тот, а не что «надо ещё чуть-чуть».
Практическая развилка
- Конструктор сайта — оффер, контент, формы, базовая SEO-гигиена. Потолок: сложная логика, кабинеты, нестандартные расчёты.
- Облачная CRM / трекер — воронка, задачи, типовые роботы. Потолок: уникальный расчёт, свои сущности «не сделка».
- Low-code — быстрее кастома на формах и простых приложениях. Потолок: сложный домен, производительность, вывоз.
- Заказной код — ваши правила и интеграции. Потолок: цена изменения, если нет команды и ТЗ.
ТЗ даже на конструктор полезно: страницы, роли, что не входит. Иначе «ещё попап, ещё калькулятор, ещё личный кабинет» превращает дешёвый проект в дорогой без решения сменить стек. Шаблон: как составить ТЗ. Выбор исполнителя, который не фанатеет от одного инструмента — как выбрать подрядчика.
С чего начать на этой неделе: запишите три сценария must-have и один «точно не в первой версии». Прикиньте, закрывает ли готовый сервис must-have без боли. Если да — пилот в нём. Если нет — узкий кастом, не «платформа компании».
Заложите миграцию заранее. Даже если остаётесь на no-code: регулярный экспорт, свои домены, доступы не на личной почте подрядчика. Если идёте в кастом — критерии приёмки и репозиторий у заказчика, иначе вы купили заложника. Сопровождение кода — разработка и сопровождение ПО.
Ошибки обеих сторон
Выбрать конструктор, потому что сосед так сделал лендинг, а вам нужен кабинет дилера. Выбрать кастом, потому что «мы IT-компания в душе», а продаёте три услуги и меняете прайс раз в год. Нанять разработчика «перенести с Tilda на React» без причины, кроме вкуса.
Игнорировать стоимость владения: тариф платформы, лишние пользователи, платные плагины, эксперт, который единственный умеет «ту связку». Игнорировать стоимость кастома: релизы ОС, библиотеки, человек, который понимает код. Обе модели требуют хозяина.
Обещать клиенту no-code «без ограничений». Ограничения всплывут на нестандартной скидке, роли, печатной форме, офлайне. Обещать кастом «как конструктор по срокам». Не строить мост: данные заявок должны уходить в учёт, какой бы ни была витрина. Иначе маркетинг в одном мире, операции — в другом.
Красные флаги в предложениях
- «Любой функционал на нашем конструкторе, без потолка».
- «Сначала всё напишем с нуля, потом подумаем, зачем».
- Нет плана вывоза данных и доступов.
- Смета без состава страниц и интеграций — одна цифра.
Типичные промахи заказчика те же, что в любой разработке: ошибки заказчика. Путаница сайта и приложения — сайт или приложение. Бюджет витрины — сколько стоит разработка сайта.
Когда не нужен кастом — и когда вреден no-code
Кастом не нужен для теста оффера, события, простой витрины, пока нет доказанного повторного сценария. Не нужен, если готовая отраслевая система закрывает 80% и вы готовы подстроиться в 20%. Подстройка процесса дешевле уникального кода, если процесс не ваше конкурентное преимущество.
No-code вреден, когда вы уже обходите платформу скриптами, боитесь обновления конструктора, не можете выполнить требование безопасности, не вывозите данные, продукт продаёте клиентам под своим SLA, а платформа в оферте «как есть». Вреден, когда единственный «разработчик» — подрядчик с доступом на личном аккаунте: уход человека останавливает компанию.
Не нужно делать выбор навсегда. Нужно назвать горизонт: 3 месяца, 12 месяцев, 3 года. На трёх месяцах конструктор часто побеждает. На трёх годах ядра продукта — чаще код или серьёзный low-code с договором и экспортом. Переписывать можно, если данные чистые и сценарии записаны. Переписывать хаос — дорого в любом стеке.
Следующий шаг
Опишите must-have сценарии и потолок «чего точно нет в v1». Проверьте готовый сервис на 80%. Если закрывает — пилот там, с экспортом и чужими доступами на компанию. Если нет — узкий заказной контур, а не «всё с нуля». Гибрид витрины и учёта чаще честнее религии «только no-code» или «только код».
Если нужен разбор границ стека — Grevin, grevin.info@mail.ru, +7 993 302-62-55.