n8n vs Make vs кастомный код: что выбрать для автоматизации с ИИ
Когда клиент приходит с задачей «автоматизировать процесс с ИИ», первое архитектурное решение — на чём это собирать. Три основных варианта: n8n, Make (бывший Integromat) и кастомный код на TypeScript/Python. Каждый годится не для всего.
Разберём, в чём практическая разница, на основе 30+ проектов, которые мы закрыли за последние два года.
Коротко: чем эти инструменты отличаются
n8n — low-code платформа для workflow-автоматизации. Self-hosted (можно поставить на свой сервер) или облако. Открытый исходный код, fair-code лицензия. Около 400 готовых интеграций, плюс возможность писать ноды на JavaScript/Python прямо в воркфлоу.
Make — облачная no-code платформа для автоматизации. Закрытый исходный код, оплата по количеству операций. Около 1700 интеграций, очень визуальный редактор. Развёртывание на своих серверах невозможно.
Кастомный код — собственный сервис на TypeScript, Python, Go. Никаких ограничений по логике, полный контроль над инфраструктурой, любая интеграция через библиотеки и SDK.
На бумаге кажется, что кастомный код всегда лучше — гибче, мощнее. На практике это не так. Гибкость стоит денег и времени, и для 60-70% задач она избыточна.
Где выигрывает n8n
n8n — наш дефолтный выбор для большинства проектов с ИИ. Причины:
Self-hosting под клиента. Ставится на VPS клиента или на наш сервер с передачей доступов. Данные не уходят в облако третьей стороны. Для B2B с чувствительными данными (CRM, переписка с клиентами, финансы) это критично.
Нативная работа с ИИ. В n8n есть встроенные ноды для OpenAI, Anthropic, Google AI, локальных моделей через Ollama. RAG через встроенные векторные базы. Цепочки агентов прямо в редакторе.
Open-source. Можно прочитать исходник любой ноды, понять, что она делает. Можно править. Можно форкнуть. С Make такой опции нет.
Адекватная цена в проде. Self-hosted версия — бесплатно. Облачная — от $24 в месяц. Для сравнения: Make на похожих объёмах стоит $30-200 в месяц.
По нашему опыту, n8n покрывает примерно 70% задач, с которыми приходят клиенты МСБ. Чат-боты с RAG, обработка заявок с CRM, контент-генерация по триггерам, мониторинг и алерты. Всё это собирается в n8n за 1-4 недели и работает годами.
Где выигрывает Make
Make хорош там, где приоритет — скорость сборки прототипа и простота для нетехнической команды.
Огромный каталог интеграций. 1700+ против 400+ у n8n. Если нужно подключить какой-то редкий SaaS — у Make обычно есть готовая нода. У n8n часто приходится писать HTTP-запрос руками.
Визуальный редактор. Make визуально приятнее, легче передать в руки маркетолога или операционщика, чтобы он сам правил мелочи.
Облачное развёртывание из коробки. Не нужно поднимать VPS, не нужно следить за uptime. Make это берёт на себя.
Где это превращается в минус:
- Данные в облаке Make. Для B2B с чувствительными данными это часто стоп-фактор.
- Vendor lock-in. Если завтра Make поднимет цены или закроется — мигрировать сложно, формат воркфлоу несовместим с другими платформами.
- Слабая работа с современным ИИ. Make догоняет, но n8n на 1-2 года впереди по нативной поддержке агентов, RAG и MCP.
- Цена при росте. Тариф считается по «операциям». В сложных воркфлоу с десятками шагов счёт за месяц быстро улетает за $200.
Кратко: Make — для маркетинговых автоматизаций, рассылок, простой обработки заявок без чувствительных данных. Не для критичной бизнес-логики и не для ИИ-агентов.
Где выигрывает кастомный код
Кастомный код нужен в трёх ситуациях.
Первая — производительность. Если нужно обрабатывать тысячи событий в секунду, low-code платформы захлёбываются. n8n начинает тормозить уже на 50-100 событиях в секунду без специальной настройки. Make упирается в свои лимиты ещё раньше. Для high-load задач — только нативный код.
Вторая — сложная логика, которая плохо ложится на ноды. Алгоритмы оптимизации, ML-модели в проде, нестандартная работа со state. В n8n это можно засунуть в Code node, но дальше становится больно поддерживать.
Третья — глубокая интеграция с существующим стеком клиента. Если у клиента уже есть монорепо на TypeScript с собственным фреймворком, плагином в их CI/CD и общими типами — иногда дешевле написать модуль в их стеке, чем выводить логику в отдельный n8n.
«У нас есть проекты на чистом TypeScript — там, где n8n был бы как пятое колесо. Но честно: 7 из 10 раз low-code платформа закрывает задачу в три раза быстрее и дешевле. Программист-перфекционист в каждом из нас сопротивляется, но реальность — таблицы в Excel и воркфлоу в n8n решают больше бизнес-проблем, чем красивая архитектура.» — Богдан Шишкин, основатель Articortex
Сравнение по параметрам
| Параметр | n8n (self-hosted) | Make | Кастомный код |
|---|---|---|---|
| Время до прототипа | 1-3 дня | 1-2 дня | 1-2 недели |
| Время до прода | 2-4 недели | 1-3 недели | 4-12 недель |
| Стоимость разработки (от) | 200 000 ₽ | 200 000 ₽ | 500 000 ₽ |
| Стоимость хостинга | от 1 500 ₽/мес (VPS) | от $24-200/мес | от 3 000 ₽/мес |
| Данные клиента | у клиента | в облаке Make | у клиента |
| Vendor lock-in | низкий | высокий | нулевой |
| Производительность | средняя | средняя | высокая |
| Поддержка ИИ-агентов | сильная | слабая | максимальная |
| Передаваемость команде клиента | средняя | высокая | низкая |
Как мы выбираем на проектах
Алгоритм простой:
- Если можно собрать в n8n за разумное время — собираем в n8n. Это дефолт.
- Если в n8n возникают костыли на каждом шагу — выносим проблемные части в кастомный код, оркестрацию оставляем в n8n.
- Если весь проект — это сплошная нестандартная логика — пишем полностью на TypeScript/Python.
- Make используем редко. Только когда у клиента уже стоит Make, в нём собрана половина процесса, и нет смысла мигрировать.
Гибридный вариант — частый случай. Например, в проекте Дельфин-клуба основной пайплайн в n8n, а pre-processing сообщений и работа с очередью Redis — отдельный TypeScript-сервис. n8n зовёт его через HTTP-ноду.
Грабли low-code
Если идёте в n8n, есть несколько мест, где наступают.
Версионирование воркфлоу. В коробке плохое. Нужно настраивать экспорт в git вручную или через комьюнити-плагины. Без этого через полгода никто не помнит, что и зачем менялось.
Тестирование. Юнит-тесты для воркфлоу — больная тема. Мы делаем «канареечные» прогоны на тестовых данных и сравниваем выход. Полноценного TDD здесь нет.
Производительность. Один большой воркфлоу с десятками нод может выполняться долго. Лучше разбивать на несколько воркфлоу с явными контрактами между ними.
Передача клиенту. n8n визуальный, но не для нетехнического человека. Не надо обещать, что «маркетолог сам будет править». Будет правка по вашему ТЗ через ваших же людей.
Что выбрать вам
Короткая шпаргалка:
- Чат-бот с базой знаний, обработка заявок, мониторинг алертов — n8n
- Маркетинговые автоматизации без чувствительных данных — Make (если уже стоит) или n8n
- High-load обработка, ML в проде, глубокая интеграция в существующий стек — кастомный код
- Не уверены — n8n как стартовая точка. Дешевле всего проверить гипотезу.
В большинстве проектов мы используем гибрид: n8n как оркестратор + кастомные сервисы там, где n8n упирается в потолок.
Что дальше
Хотите понять, на чём собрать конкретно ваш процесс — приходите с описанием задачи. Часто решение очевидно после 15 минут разговора. Грубая оценка — /calculator. Предметный диалог — /contacts.
См. также: