No-code или код: на чём собирать первый продукт

Вопрос «no-code или код» фаундеры задают так, будто выбирают технологию на годы. На самом деле выбирается другое: как быстро вы получите ответ на свою гипотезу и во что вам обойдётся ошибка.

С этой точки зрения ответ почти всегда одинаковый: начинайте с самого дешёвого инструмента, который способен дать честный ответ. Часто это вообще не продукт, а таблица и человек.

Лестница инструментов

Расположим варианты по возрастанию стоимости ошибки.

1. Руками. Вы делаете работу за клиента лично: собираете отчёт ночью в таблице, обзваниваете поставщиков, ведёте заказы в блокноте. Стоимость входа — ноль, скорость — часы. Отвечает на вопрос «готовы ли люди за результат платить».

2. Готовые кубики. Форма + таблица + чат-бот + сервис автоматизации. День-два работы, никакого программиста. Отвечает на вопрос «работает ли процесс, если его немного ускорить».

3. No-code платформа. Конструктор приложений с базой, ролями и интерфейсом. Неделя-две. Отвечает на вопрос «пользуются ли люди этим регулярно, без нас за плечом».

4. Код. Свой бэкенд, своя база, свой фронтенд. Недели и месяцы. Отвечает на вопрос «выдержит ли это нагрузку, интеграции и требования, которые уже подтверждены деньгами».

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

Когда no-code — правильный выбор

Гипотеза про спрос, а не про технологию. Вы проверяете, нужен ли людям результат. Как он получен — им безразлично.

Мало пользователей и много неизвестного. Пока вы меняете логику продукта каждую неделю, любая архитектура — обуза. На конструкторе переделка занимает вечер.

Внутренний процесс. Админка, обработка заявок, учёт — здесь готовые инструменты живут годами и не мешают никому.

Нет технического сооснователя, а проверить надо сейчас. Ждать полгода, пока найдётся разработчик, — худший вариант из всех. Про поиск партнёра — отдельная статья.

Когда no-code — тупик

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

Требования к данным. Персональные данные, медицинская или финансовая информация, требования по хранению внутри страны — на этом месте разговор о конструкторе обычно заканчивается.

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

Интеграции, которых нет в списке. Как только нужна нестандартная интеграция, вы всё равно пишете код — только теперь внутри чужой песочницы и с её ограничениями.

Признаки, что пора переписывать

Переписывание — не поражение, а нормальный этап. Плохо не переписать вовремя. Сигналы:

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

Достаточно двух-трёх пунктов, чтобы начать планировать переход. Важно: переходить нужно с работающим потоком клиентов, а не «сначала перепишем, потом продадим».

Как переписывать, чтобы не убить продукт

Не переписывайте всё сразу. Начните с той части, где ограничения болят: обычно это ядро данных или самая нагруженная операция.

Сохраните ручные куски. То, что делается руками и не мешает, оставьте руками. Автоматизировать стоит только то, что уже стало узким местом.

Считайте перенос данных отдельной задачей. Именно на ней ломаются сроки: экспорт из конструктора почти всегда неполный.

Не начинайте с красоты. Первая версия на своём стеке должна повторить существующее поведение, а не улучшить его. Улучшения — следующим шагом, иначе не с чем сравнивать.

Как мы решаем этот вопрос в лаборатории

Мы почти всегда начинаем с ручного режима и готовых кубиков — просто потому, что на первом этапе проверяется не архитектура, а спрос. Свой код появляется тогда, когда выполнены два условия: гипотеза подтверждена платящими пользователями и понятно, какая именно часть продукта должна работать надёжно.

Такой порядок экономит самое дорогое — месяцы. Продукт, написанный сразу и целиком, обычно оказывается идеально сделанным ответом на вопрос, которого никто не задавал. Про то, как этот вопрос формулируется, — в статье про MVP.