Как выбрать no-code платформу в 2026: критерии, сравнение и чек-лист

Почему выбор no-code платформы так легко испортить

Почти каждая команда проходит через один и тот же сценарий. Сначала появляется задача, для которой нет готового решения: внутренняя админка, лендинг, приложение для мобильной бригады, автоматизация между CRM и таблицами. Разработчиков не хватает или их вообще нет. Кто-то предлагает: «Давайте сделаем на no-code». Находится первая попавшаяся платформа, за вечер собирается прототип — и через три месяца выясняется, что данные лежат в чужом облаке, экспорт стоит денег, а часть логики вообще нельзя перенести.

Проблема не в самой технологии. Проблема в том, что no-code — это не один инструмент, а десяток очень разных, и выбирать их нужно под задачу, а не по красоте демо. По данным Gartner, к 2025 году около 70% новых приложений в компаниях создавались с использованием low-code или no-code подходов — рынок огромен, и маркетинг у всех поставщиков одинаково громкий.

Эта статья — про то, как выбрать платформу осознанно: какие вопросы задать до регистрации, чем отличаются типы инструментов, как посчитать реальную стоимость и где пройдёт граница, за которой no-code начинает мешать. В конце — пошаговый чек-лист, по которому можно прогнать любую платформу за один вечер.

No-code и low-code — в чём разница и почему это важно для выбора

Термины часто используют как синонимы, но разница принципиальная и напрямую влияет на выбор.

No-code — платформы, где всё собирается визуально: перетаскиванием блоков, настройкой условий в интерфейсе, без написания кода. Примеры: Bubble, Glide, Softr, Airtable Automations, Zapier. Порог входа минимальный, но возможности ограничены рамками конструктора.

Low-code — те же визуальные конструкторы, но с «люком» для кода: можно вставить JavaScript, SQL-запрос, собственный API-вызов, написать кастомный компонент. Примеры: Appsmith, ToolJet, Budibase, Retool, Webflow с кастомным кодом. Здесь порог выше, зато не будет стены, когда логика станет сложной.

Практический вывод простой: если вы планируете что-то сложнее простой формы и таблицы — сразу смотрите в сторону low-code. Платформы no-code хороши для быстрых запусков, но переход с «чистого» no-code на что-то серьёзное обычно означает переписывание с нуля. Low-code платформа растёт вместе с задачей: сегодня вы собираете админку мышкой, завтра добавляете кастомный SQL-запрос, послезавтра — свой компонент.

Отдельная категория — автоматизация процессов (Make, Zapier, n8n, Airtable Automations). Это не конструкторы приложений, а «клей» между готовыми сервисами. Их часто путают с платформами разработки, хотя задача у них другая: соединить два существующих инструмента, а не создать новый.

И наконец сайтостроители (Webflow, Softr, Framer) — визуальная разработка веб-страниц. Они ближе к веб-дизайну, чем к приложениям, и нужны, если цель — публичный сайт, а не внутренний инструмент.

Кому и когда действительно нужна no-code платформа

Прежде чем сравнивать функции, честно ответьте, ваша ли это вообще история. No-code выигрывает в трёх сценариях.

Первый — внутренние инструменты. Админки, панели операторов, дашборды поддержки, инструменты для отдела продаж. Классическая боль: «нужна одна кнопка, чтобы перевыпустить лицензию клиенту», а классический путь — две недели работы React-разработчика и годы поддержки. Low-code платформы вроде Appsmith и ToolJet созданы ровно для этого: подключаете базу данных, drag-and-drop собираете интерфейс, публикуете.

Второй — проверка гипотез. Нужно за неделю показать инвесторам или клиентам рабочий прототип, а не презентацию. Здесь no-code незаменим: скорость запуска важнее архитектурной чистоты.

Третий — автоматизация рутины. Копирование данных между сервисами, обработка заявок, отчёты по расписанию. Здесь работают Make, Zapier и n8n — не конструкторы приложений, но мощные сценарии автоматизации.

Когда no-code не нужен: если у вас есть команда разработчиков, готовых сделать сервис правильно, если проект критичен по нагрузке (тысячи одновременных пользователей), если есть жёсткие требования к безопасности и хранению данных, или если продукт — ваша основная бизнес-ценность, которую нельзя привязывать к чужой платформе.

Восемь критериев выбора no-code платформы

Вот критерии, которые реально влияют на решение. Проходите их по порядку — они расставлены от «стоп-факторов» к приятным мелочам.

1. Модель развёртывания: облако или self-hosted. Это первый и, пожалуй, самый важный вопрос. Облако — быстрый старт, но ваши данные лежат у вендора, а тарифы растут с числом пользователей. Self-hosted — вы разворачиваете платформу на своём сервере, данные остаются внутри периметра, а цена фиксированная. Для внутренних инструментов с доступом к базам сотрудников и клиентов self-hosting почти всегда правильный выбор. Appsmith, ToolJet, Budibase и n8n открыты и ставятся на собственный VPS или в Kubernetes.

2. Модель ценообразования: за пользователя или за приложение. Платформы вроде Retool и Bubble берут деньги за каждого пользователя в месяц. Внутренняя админка на 40 сотрудников легко превращается в счёт на сотни долларов ежемесячно. Платформы с открытым кодом (Appsmith, ToolJet) не лицензируют каждого пользователя — вы платите за инфраструктуру. Считайте не «цену плана», а стоимость при вашем числе пользователей и через три года, а не в первый месяц.

3. Подключение к источникам данных. Платформа должна уметь то, что есть у вас: PostgreSQL, MySQL, MongoDB, REST API, Google Sheets, внутренние сервисы. Проверьте не список коннекторов на сайте, а наличие нужного вам конкретно. Если базы нет в списке нативно, узнайте, можно ли подключить через REST или драйвер.

4. Гибкость логики. Можно ли написать собственный SQL-запрос? Добавить JavaScript-трансформацию ответа? Вызвать внешний API? Чем раньше упрётесь в «это нельзя», тем дороже будет миграция. Low-code с «люком» для кода здесь выигрывает у чистого no-code.

5. Экспорт и отсутствие вендор-лока. Что произойдёт, если платформа закроется или поднимет цены вдвое? Можете ли вы экспортировать приложение и данные? Открытые платформы (self-hosted) дают реальный контроль: код и данные остаются у вас. Проприетарные облака — часто ловушка.

6. Интеграции и API. Нужны вебхуки, REST, GraphQL, авторизация по OAuth, SSO. Для внутренних инструментов критичны SSO (Google, LDAP, SAML) и разграничение прав — иначе половина сотрудников увидит то, что не должна.

7. Экосистема и поддержка. Активное сообщество, документация, регулярные релизы, платный support. Проверьте дату последнего релиза на GitHub и активность в трекере. Мёртвый проект — риск целого стека.

8. Кривая обучения. Насколько быстро ваша команда начнёт работать без разработчика? Хорошие платформы дают готовые шаблоны и понятный drag-and-drop. Плохие — требуют читать документацию месяц, чтобы сделать простую форму.

Обзор основных платформ: с чем сравнивать

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

Закономерность видна сразу: чем ближе платформа к «создать приложение», тем чаще это self-hosted low-code с фиксированной ценой; чем ближе к «создать сайт или таблицу», тем чаще чистое облако с оплатой за пользователя. Выбирайте категорию под задачу, а не «лучшую платформу вообще» — её не существует.

Self-hosting и инфраструктура: где no-code встречается с сервером

Как только вы выбираете self-hosted платформу (а для внутренних инструментов это обычно верно), появляется отдельный вопрос — на чём её размещать. Облачная версия Appsmith или ToolJet снимает эту заботу, но возвращает все минусы облака: данные у вендора, оплата за пользователя, зависимость от чужого аптайма.

Своё развёртывание даёт контроль и предсказуемую стоимость, но требует сервера. Здесь важны три вещи: память (no-code платформа — это веб-приложение плюс база, чаще всего нужно 4–8 ГБ RAM для комфортной работы), диск (быстрый SSD под базу и логи) и сеть (стабильный канал, если инструментом пользуются сотрудники из офиса или удалённо).

Для российских команд под эти задачи хорошо подходят локальные VPS-провайдеры — данные и трафик остаются в стране, поддержка на русском, оплата в рублях. Например, VDSina даёт почасовую оплату и быстрый старт, что удобно для пилота, а FirstVDS — предсказуемые тарифы и простые в настройке VPS на Ubuntu, на котором Appsmith и ToolJet разворачиваются в один docker compose up. Для продакшена берите минимум два ядра и 4 ГБ RAM, а под базу — отдельный том.

⚠️ Отдельно проверьте требования платформы к версии Docker и Kubernetes, если планируете кластер. Компактные инсталляции на одном сервере работают годами, но с ростом числа приложений аппетит к памяти растёт, поэтому оставляйте запас.

Сколько это стоит: как считать правильно

Почти все ошибаются на этом шаге. Считают цену тарифа, а не стоимость владения.

Облачные платформы с оплатой за пользователя. Формула проста: цена за пользователя × число пользователей × 12. Внутренний инструмент, которым пользуются 30 сотрудников по $15 в месяц, — это $5 400 в год. И это только за платформу, без вашего времени.

Self-hosted. Фиксированная цена сервера: VPS на 4 ГБ RAM стоит в районе нескольких сотен рублей в месяц, то есть тысячи рублей в год — на порядок дешевле облака при том же числе пользователей. Но добавьте стоимость администрирования: обновления, бэкапы, мониторинг. Если у вас нет человека, который это делает, «дешевле» может оказаться дороже.

Автоматизация. Make и Zapier считают операции (запуски сценариев). Тысячи операций в месяц накапливаются незаметно. Self-hosted n8n снимает лимит, но требует того же сервера, что и выше.

Правило расчёта: сравните два сценария за три года — облако и self-hosted. Учтите число пользователей через год (оно обычно растёт), стоимость администрирования и риск роста тарифа. Обычно облако выигрывает на 3–5 пользователях, self-hosted — начиная с 15–20.

Пять ошибок, которые совершают почти все

Ошибка 1. Выбор по красоте демо. Демо-ролики показывают идеальные данные и идеальный сценарий. Прогоняйте платформу на своей реальной, грязной базе, прежде чем решать.

Ошибка 2. Игнорирование вендор-лока. Если данные и логику приложения нельзя выгрузить, вы не владеете своим инструментом — вы его арендуете. Читайте условия экспорта до регистрации, а не после.

Ошибка 3. Расчёт цены по первому месяцу. Тарифы почти всегда растут, а скидки для новых клиентов не вечны. Считайте три года и реальное число пользователей.

Ошибка 4. Один инструмент на всё. Пытаться сделать и сайт, и внутреннюю админку, и автоматизацию в одной платформе — верный путь к компромиссам. Возьмите Webflow для сайта, Appsmith для админки и n8n для автоматизации.

Ошибка 5. Отсутствие плана выхода. Даже если сейчас всё устраивает, держите в голове: как вы переедете, если платформа закроется? Открытые self-hosted платформы дают запас прочности, облачные — нет.

Пошаговый чек-лист выбора

Прогоните любую платформу по этим пунктам — на всю проверку уйдёт один вечер.

1. Определите задачу. Внутренний инструмент, публичное приложение, сайт или автоматизация? От этого зависит категория.
2. Проверьте модель развёртывания. Есть ли self-hosted? Нужен ли он вам по требованиям безопасности?
3. Посчитайте стоимость на 3 года при вашем реальном числе пользователей, а не на первый месяц.
4. Соберите пилот на своих данных — пусть даже на бесплатном тарифе. Не на демо-данных.
5. Проверьте коннекторы к вашим базам и внутренним API.
6. Оцените гибкость логики. Есть ли SQL, JavaScript, кастомные компоненты?
7. Проверьте экспорт приложения и данных. Вендор-лок — стоп-фактор.
8. Оцените экосистему. Дата последнего релиза, активность комьюнити, документация.
9. Прогоните с командой. Посмотрите, справится ли непрограммист сделать простую форму.
10. Зафиксируйте план выхода. Как мигрируете, если что-то пойдёт не так.

Вердикт

No-code и low-code — зрелые технологии, и вопрос давно не «стоит ли ими пользоваться», а «какой из них подходит вашей задаче». Универсального победителя нет: Bubble выигрывает в скорости создания веб-приложения, Webflow — в сайтах, Make и n8n — в автоматизации, а для внутренних инструментов и админок лучше всего подходят открытые low-code платформы вроде Appsmith, ToolJet и Budibase.

Главный вывод прост: начинайте с задачи и требований к данным, а не с платформы. Если данные должны остаться внутри компании, если пользователей много и они растут, если логика будет усложняться — выбирайте self-hosted low-code и размещайте на своём VPS. Это дешевле облака на масштабе, безопаснее по данным и устойчивее к капризам вендора. Если же нужен быстрый публичный запуск без команды разработчиков — облачный no-code сделает работу за вечер.

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