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

Собрали команду из трёх человек: таргетолог (инициатор), я (product manager) и один full-stack разработчик.

Мне, как всегда, досталось самое весёлое — организовать всё, чтобы остальные приступили к своим узким задачам. Дабы обеспечить максимальный операционный простор, я решил сделать фронт на WordPress. За вечер, при помощи бесплатного шаблона и матерных слов, фронт был готов. Дело оставалось за малым: написать бэк, подключить платежи и запустить рекламную компанию. На всё ушло ещё две недели. После запустили первую рекламу с небольшим бюджетом.

Спустя пять дней наш таргетолог, человек импульсивный, заявил, что фронт получился «не ахти». А вот сделанная им страница на Tilda показала себя куда лучше. Вопреки моему сопротивлению — ибо я отдавал себе отчёт, что представляет из себя сей конструктор, — большинством голосов (мой одинокий голос против двух) решение было принято.     Нюансы начались сразу.

Первый акт. Блоки, которые не дружат

Оказалось, что блок форм BF-204 не работает с блоком ST-105 для оплаты без корзины. А корзина нам была нужна как пятое колесо телеге. Пришлось юзать блок ST-100, а форму пихать внутрь корзины. Но, как оказалось, встроенный в ST-100 функционал форм сильно уступает по возможностям BF-204. Первое разочарование.      Второй акт. Вебхуки, которые летят к чёрту

Следующая иллюзия: «необычайная лёгкость» настройки рекламы благодаря встроенной интеграции с ЮKасcой. Мол, оплата подтвердилась — и вебхук сразу летит на бэк. На деле же вебхук приползал с опозданием от 3 до 18 часов. При нашем заявленном сроке генерации результата в 15 минут это был приговор. Сначала грешили на ЮKассу, но нет: время жизни payment_url в ЮKассе — 1 час (после нашего обращения его сократили до 10 минут). То бишь ЮKасcа просто физически не могла так задерживать оповещение. Неделя переписки с техподдержкой Tilda, вторая линия просит «актуальный пример». Но к тому моменту мы уже переписали логику бэка. Осознание: вы не контролируете критичные процессы — вы просто просите.

Третий акт. [0] Unknown error. Please try again later

Потом на нас посыпались жалобы от пользователей, которые не могли отправить форму. Tilda награждала их ошибкой [0] Unknown error. Please try again later.. Обращаемся в поддержку — получаем отписку: «Это или проблемы с интернетом у пользователя, или он часто ошибался в капче». Я таки смог отловить эту ошибку, и знаете, сколько раз мне выдало капчу? Ровно 0! Tilda насильно вставляет ReCaptcha в формы, и её нельзя полностью отключить. Можно только выбрать уровень проверки. Ваши пользователи видят ошибку, а вы не можете ничего сделать. Это не ваша платформа — вы в ней просто арендатор.

Финальный акт. Чёрный ящик и нулевая кастомизация

Венчала всё попытка настроить передачу ClientID в ЯндексМетрику через кастомный скрипт. Нам нужно было понять, в каком проценте случаев скрипт не отрабатывает (ибо работает он через Fetch-запрос, а он бывает блокируется браузерами). В обычном случае можно поставить счётчик загрузок и сравнить с количеством пришедших вебхуков. Но Tilda работает на своих серверах. Ни кастомизировать логи, ни поставить свой скрипт для трекинга каждого события нельзя. Вы не можете проверить гипотезу. Не можете быть уверены. Вы просто верите.

Резюме (или зачем я это всё рассказываю)

Всё это — не случайные баги, а системные особенности платформы. Tilda — это прекрасный конструктор для лендингов и визиток. Но она остаётся именно конструктором, жёстко заточенным под свои парадигмы, без каких-либо существенных возможностей по кастомизации.

Когда вы делаете серьёзный сервис с платежами, сложной логикой и зависимостью от времени, вы упираетесь в потолок. Вы боретесь не с задачей, а с платформой.

Для таких проектов нужны инструменты, дающие полный контроль: WordPress с его выбором плагинов и возможностью кастомизации кода или Next.JS. На последний мы и решили постепенно переехать. Но это, уже другая история.