No-code и собственная разработка

No-code — это создание приложения преимущественно через готовые блоки и настройки. Собственная разработка означает, что нужную логику пишут программным кодом под вашу задачу. Выбор зависит от требований, рисков, доступных специалистов и стоимости изменений. Название подхода само по себе не гарантирует ни быстроты, ни надёжности.

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

Сначала опишите обязательный рабочий сценарий

Составьте короткое описание того, что должно работать сейчас. Кто входит, какие данные создаёт, кто их видит, что происходит при ошибке, какой результат получает. Отдельно запишите требования к оплате, правам доступа, резервному копированию, скорости, устройствам и доступности сервиса в нужных странах.

Разделите сегодняшние требования и будущие предположения. «Возможно, когда-нибудь будет миллион пользователей» не помогает выбрать первую версию. А необходимость уже сейчас скрывать заявки одной мастерской от другой — реальное требование. Нельзя отложить его как украшение интерфейса.

Для каждой обязательной возможности запросите демонстрацию или проведите небольшой технический опыт. Фраза «это можно через интеграцию» требует уточнения: с каким сервисом, на каком тарифе, кто поддерживает связь и что происходит при сбое. Набор соединённых инструментов тоже является системой, которую кто-то должен понимать.

Проверьте выход из выбранного решения

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

Например, документация Bubble сообщает, что приложение работает на платформе Bubble и не экспортируется в виде кода для самостоятельного запуска; при переходе логику потребуется воссоздавать. Это характеристика конкретной платформы, а не всех no-code-инструментов. Для другого сервиса проверяйте его собственные условия.

В собственной разработке также возможна зависимость: от одного программиста, редкой технологии, недоступных учётных записей или отсутствия документации. Уточните права на код и доступ к репозиторию, размещению, домену и внешним сервисам. «Код наш» мало помогает, если только подрядчик знает, как запустить рабочую версию.

Считайте владение, а не только запуск

Учебное сравнение на шесть месяцев: настройка no-code стоит 60 000 рублей, тарифы и внешние сервисы — 8 000 в месяц, поддержка и изменения — 12 000. Итого 180 000 рублей: 60 000 + 6 × 20 000. Собственная версия стоит 240 000 на запуск, 5 000 в месяц на инфраструктуру и 15 000 на поддержку — всего 360 000.

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

No-code за шесть месяцев

Запуск 60 000 рублей, месяц 8 000 плюс 12 000. Итого 180 000 рублей.

Своя версия

Запуск 240 000, месяц 5 000 плюс 15 000. Итого 360 000 рублей.

В примере месячная сумма совпала: 20 000 рублей. Это не рыночные цены. Налоги, комиссии и труд владельца не входят. Стоимость возможного переноса называют заранее.

Дешёвая первая версия может быть разумной даже при будущей миграции, если помогает быстро проверить неизвестный спрос. Но стоимость возможного переноса нужно назвать заранее. И наоборот: дорогая разработка оправдана не престижем, а требованиями, которые действительно важны и не решаются выбранными готовыми средствами.

Назначьте ответственного за надёжность

В конструкторе настройка прав доступа остаётся содержательной работой. Например, Bubble описывает серверные правила приватности, определяющие, какие данные получает пользователь. Скрыть элемент на странице — не то же самое, что правильно ограничить доступ к данным. Проверяйте продукт с разными ролями и чужими записями, а не только из учётной записи владельца.

Для обеих схем определите, кто следит за сбоями, обновляет зависимости или настройки, восстанавливает данные и отвечает клиентам. Автоматизация без ответственного не устраняет ручную работу: она переносит её в момент, когда что-то перестало работать.

Доступность сервисов, способы оплаты и требования к обработке данных проверяйте для своего бизнеса и страны. Хорошо описанный зарубежный инструмент может не подходить по условиям подключения. Эта проверка предшествует выбору, а не проводится после продажи доступа клиентам.

Практическое задание

Сравните два конкретных варианта по одному сценарию. Для каждого заполните: обязательные функции; подтверждённые ограничения; стоимость запуска и шести месяцев; ответственный; способ выгрузки и переноса; наиболее болезненный сбой.

Проверьте самый рискованный пункт небольшим опытом до большого договора. Решение сформулируйте так: «На ближайший этап выбираем этот вариант, потому что он выполняет такие требования; к выбору вернёмся, когда возникнет такое ограничение». Это позволяет действовать сейчас и не выдавать временное решение за окончательную архитектуру бизнеса.