Сравнение

Граница проходит между разговором и вычислением

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

Граница проходит между разговором и вычислением: решение в фактах

С чем сравниваем: Конструктор без кода
Сравнили измерений: 8, включая ветвление разговора и вычисления на живых данных
Где мы проигрываем: скорость итераций: Минуты в конструкторе против цикла разработки здесь

As of 2025-10-01, Telegram Bot API 13.4

Что здесь на самом деле сравнивается

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

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

Формально до этих операций можно дотянуться через внешний вызов конструктора, и результат обычно выходит хуже любого из двух чистых вариантов. Логика оказывается разорвана между визуальным сценарием, который невозможно протестировать, и внешним сервисом, который никто не описал, а для отладки нужно держать в голове оба сразу. Там, где боту нужно настоящее вычисление, делать его в одном месте — не пуризм, а разница между системой, которую кто-то способен поддерживать, и системой, к которой никто не хочет прикасаться.

Построчное сравнение

Критерий	конструктор без кода	Заказная разработка
Ветвление разговора	Отлично. Визуально, понятно с первого взгляда и меняется без разработчика.	То же самое по поведению, но менять без разработчика заметно тяжелее.
Вычисления на живых данных	Плохо. Внешние вызовы есть, и они рвут логику надвое, а общего владельца у неё нет.	Обычная работа. Доступность, цены и сверка — это просто код.
Корректность при одновременном доступе	Не решается. Удержать ресурс атомарно из визуального сценария попросту нечем.	Делается явно, и именно это не даёт двум клиентам занять один слот.
Тестирование	Вручную, проходом по сценарию. Регрессия большого сценария практически невозможна.	Автоматическое. Весь сценарий прогоняется на сборке при каждом изменении.
Обработка сбоев	Что сделает платформа, то и будет, — обычно остановится. Очередь повторов не добавить.	Явная. Повторы, недоставленные сообщения и оповещения проектируются, а не наследуются.
Скорость итераций	Минуты, своими руками. Сильнейший аргумент за то, чтобы остаться.	Цикл разработки, если настраиваемость не заложили осознанно заранее.
Стоимость за три года	Подписка, растущая вместе с использованием. Предсказуемая и ничем не ограниченная сверху.	Разовая разработка плюс копеечный хостинг. Больше вначале, дальше ровно.
Стоимость выхода	Переделывать с нуля. Сценарии не переносятся никуда вообще.	Код ваш, и любой грамотный разработчик способен его продолжить.

Что подойдёт именно вам

Ваш выбор — конструктор без кода, если

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

Ваш выбор — заказная разработка, если

Решение внутри сценария зависит от живого состояния другой системы.
Двое могут захотеть одно и то же одновременно, а достаться оно должно только одному.
Двигаются деньги, и сбой обязан повториться, а не остановить процесс.
Бот — часть продукта, а не маркетинговый канал, и его надёжность равна вашей собственной.
Нужна возможность Telegram, которую конструктор не отдаёт, а для Mini Apps и Stars это почти все возможности сразу.

В чём мы проигрываем

Скорость итераций, и решительно. Конструктор меняется за минуты, заказной бот — за цикл разработки. Для команды, которая еженедельно правит тексты, эта разница перевешивает очень многое.
Доступность для тех, кто не пишет код. Человек из маркетинга может полностью владеть сценарием в конструкторе. Владеть репозиторием он не может, и попытка сделать вид, что может, кончается ботом, которого никто не поддерживает.
Стартовые деньги и время. Не бывает заказной разработки, которая заработает сегодня к вечеру за стоимость подписки, и бизнесу, которому нужно именно это, читать эту страницу незачем.
Риск на непроверенной идее. Тратить бюджет разработки на бота, спрос на которого никто не подтвердил, хуже, чем проверить идею в конструкторе и переписать заново то, что взлетело.

Если вы уже там: как проходит переезд

Найти костыль
В любом сценарии, переросшем свой конструктор, есть ручной шаг: кто-то смотрит календарь, правит таблицу, подтверждает платёж руками. Этот шаг и есть то требование, которое инструмент не потянул, и именно ради него затевается переделка.
commands
Померить сценарий до того, как его менять
Доходимость по шагам, в существующем инструменте, до любой переделки. Без базовой цифры доказать, что переделка помогла, невозможно, а спросят об этом рано или поздно обязательно.
webhook
Переписать только несущий сценарий
Не весь аккаунт. Один сценарий, тот самый с костылём, работающий рядом с конструктором, за которым остаётся всё прочее. Переезд одним рывком меняет работающие сценарии на непроверенные без всякой причины.
webhook
Разделить трафик и сравнить по той же метрике
Новый сценарий забирает долю новых разговоров. Сравнение с базовой цифрой на том же шаге и отвечает, стоила ли переделка потраченного, — на такой вопрос полезно уметь отвечать цифрой.
deep-link
Решить, что где остаётся
Обычный итог — не полная замена. Транзакционные сценарии переезжают, простые разговорные остаются, потому что конструктор в них по-прежнему лучше, а приза за сведение всего в одно место никто не выдаёт.
commands

О чём спрашивают, когда выбирают

Как понять заранее, на какой стороне этой границы мы находимся?

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

Почему не воспользоваться внешним вызовом прямо из конструктора?

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

Всегда ли стоит сначала собрать прототип в конструкторе?

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

Что ломается первым, когда конструктор перерастают?

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

Заказного бота тяжелее поддерживать, чем сценарий в конструкторе?

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

Могут ли оба варианта работать одновременно и постоянно?

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

Что почитать дальше

Тот же довод, но против конкретного продукта, — смотрите сравнение с ManyChat.

Когда альтернатива — готовый продукт, а не конструктор, читайте сравнение «сделать или купить».

Задача одновременного доступа, описанная выше, по шагам разобрана здесь — разбор бота записи.

Чтобы посчитать эту арифметику против собственной подписки, посмотрите, во что обходится заказная разработка.

Когда ответом стал код, следующий вопрос — кто его пишет; на него отвечает сравнение фрилансера и студии.

Получить фикс-смету в TelegramРасскажите, какому шагу вашего сценария нужен живой ответ