Конструктор или код: что выбрать
Спор "конструктор или код" обычно ведут неправильно. Стороны сравнивают стоимость разработки и упускают, что у конструктора цена растянута во времени, а у кода собрана в начале. Именно от этого зависит ответ, и для разных задач он оказывается разным.
Где конструктор действительно выигрывает
Конструктор представляет собой чужую платформу, на которой вы собираете бота или сайт из готовых блоков, чаще всего мышкой. Для сайтов это Тильда, Wix и подобные им площадки, для ботов отдельные конструкторы, устроенные по тем же правилам. Вы платите помесячно, а платформа берёт на себя серверы, обновления и работоспособность. Порог входа здесь почти нулевой, ведь простого бота с меню и приёмом заявок реально собрать за вечер без разработчика.
Это честное преимущество, и обесценивать его не надо. Если задача состоит в том, чтобы проверить наличие спроса, конструктор выигрывает у кода вчистую. Гипотеза, которая не подтвердилась, обошлась в тысячу рублей и один вечер, а не в тридцать тысяч и неделю ожидания. То же касается разовых вещей вроде бота на время мероприятия, записи на один поток или витрины до конца сезона.
Про Тильду стоит сказать отдельно, потому что спрашивают чаще всего именно про неё. Для лендинга, сайта услуг и небольшой витрины она делает ровно то, что обещает: страница собирается быстро, выглядит прилично и правится без разработчика. Ограничения у неё те же, что у любого конструктора, и начинаются они на своей логике, своих интеграциях и переносе всего этого на другую площадку. Подписка при этом идёт помесячно и в смету на запуск обычно не попадает, хотя за три года набегает сумма, сравнимая с разработкой.
Три потолка, в которые упирается конструктор
Потолок у конструктора всё же есть, и упираются в него всегда в одном месте: когда логика перестаёт быть линейной. Пока сценарий выглядит как последовательность вопросов, ответов и заявки, всё идёт хорошо. Как только появляется условие вида "если подписка активна и город такой-то, показать другой список, иначе предложить оплату и после неё вернуться на шаг назад", начинается борьба с платформой. Собрать это можно, однако собранное будет хрупким, и никто, кроме автора, в нём не разберётся.
Второй потолок связан с интеграциями. Конструкторы подключают популярные сервисы, но популярные у них, а не у вас. Ваша учётная система, отраслевой сервис или самописная база в список не входят. Иногда выручает вебхук общего назначения, однако сложные обмены через него собираются с трудом, а отлаживать их почти нечем.
Третий потолок, самый неприятный, касается данных и зависимости. База ваших клиентов лежит у платформы. Выгрузка обычно предусмотрена, но выгружаются данные, а не логика: сценарии, настройки и связи придётся собирать заново на новом месте. Поэтому решение уйти всегда откладывается, а абонентская плата продолжает капать. Добавьте к этому, что платформа может поменять тарифы, убрать нужную функцию или закрыться, и повлиять на это вы никак не сможете.
Что даёт собственный код и чего он стоит
У кода набор свойств обратный. Он дороже и дольше на старте, зато дальше ограничений практически нет: любая логика, любые интеграции, свой интерфейс, свои правила. Ежемесячно вы платите за сервер, а не за право пользоваться собственным продуктом. Исходный код принадлежит вам, и это не абстракция: с ним проект передаётся другому разработчику, а без него не передаётся никак.
Минусы у кода тоже настоящие, и обычно их замалчивают. Разработку приходится ждать. Мелкую правку текста не внести самостоятельно, если под неё не сделали админку. Сервер кто-то должен обслуживать. Качество при этом целиком зависит от исполнителя, ведь плохо написанный код хуже любого конструктора, потому что чинить его дороже, чем переписать.
Как выбрать под свою задачу
Практическое правило получается довольно простое. Если вы проверяете идею, сроки горят и бюджет маленький, начинайте с конструктора и не слушайте разработчиков, включая нас. Если продукт работает, приносит деньги, а вы упираетесь в ограничения платформы, пора переходить на код. Если же задача изначально нетиповая или связана с деньгами, чужими данными и внешними системами, конструктор не подойдёт и время на попытку уйдёт впустую.
Промежуточный путь и момент для переезда
Существует и промежуточный путь, о котором говорят редко: оставить в конструкторе то, что там работает хорошо, и вынести в код только узкое место. Приём заявок и оплата остаются на платформе, а расчёт, выгрузка или интеграция с вашей системой живут отдельным сервисом, который платформа дёргает по вебхуку. Архитектура получается не самая красивая, зато переписывать всё разом не приходится.
Если переезжать всё-таки придётся, дешевле сделать это раньше. Чем дольше продукт живёт на платформе, тем больше в нём накапливается настроек, которые нигде не описаны, и тем больше времени уходит на восстановление логики по скриншотам. Удобным моментом для переезда считается тот, когда абонентская плата за год начинает подбираться к стоимости разработки. Тогда это уже не спор о вкусах, а арифметика.