Всем привет, я сооснователь мессенджера Пачка и отвечаю, в том числе, за маркетинговую инфраструктуру. 

Нам нужно было оперативно увезти наш сайт с Webflow: 500+ страниц, блог и база знаний. При этом возвращать фронтенд-разработку в режим постоянной поддержки сайта мы не хотели. Поэтому рассматривали конструкторы и CMS, но быстро поняли, что это будет работа в минус. Все усилия на переезд лишь вернули бы сайт в рабочее состояние, не дав новых возможностей.

В итоге мы решили вести разработку и поддержку сайта в Cursor. То есть переписать его на NextJS с помощью AI агентов. Такая связка дала понятную модель страниц, быструю доставку статики и ISR для контента, а также возможность отказаться от отдельной CMS за счёт MDX.

В спокойном режиме за два месяца удалось полностью переписать сайт и запустить ��го в прод. Ниже делимся практическим опытом этого переезда.

За последние десять лет мы в своих проектах прошли полный круг: от самописных страниц к Webflow и обратно к собственному сайту.

Каждый такой переход воспринимался как качественный скачок. Переезд на Webflow в своё время сильно упростил жизнь. Фронтенд-команда полностью перестала участвовать в развитии маркетинговой витрины — сайта, блога и базы знаний. Всё создавалось и развивалось командой маркетинга (1), что заметно ускорило цикл обновлений. Страниц стало больше, и сайт начал регулярно обновляться.

Почему решили съезжать с Webflow

Изменение ценообразования
Webflow резко поменял модель оплаты. Если раньше мы платили фиксированную подписку, то с прошлого года сервис перешёл на оплату за трафик. С учётом того, что у нас сотни тысяч пользователей, которые часто заходят на сайт просто чтобы перейти в приложение, это стало ощутимо. На пике, даже с учётом скидок, чек доходил до 10 000 долларов в год. Это не стало единственной причиной для переезда, но заметно пошатнуло лояльность к сервису.

Блокировки и инфраструктура
Cloudflare и IP-адреса AWS, на которых хостится Webflow, периодически попадали под блокировки. Это создавало реальные проблемы с доступностью сайта. В качестве временного решения нам даже пришлось поднимать собственный прокси.

Вопросы доверия со стороны пользователей
Нам регулярно приходилось объяснять, действительно ли сервис российский, если лендинг хостится на Amazon. Пользователи редко вникают в архитектуру и не всегда понимают, что само приложение хостится в РФ. Чаще они смотрят на сайт и делают быстрые выводы.

Из чего выбирали

По инерции мы сначала смотрели в сторону конструкторов и CMS. Зарубежные решения не рассматривали, сфокусировались на российских платформах.

Первым очевидным вариантом была Tilda. Быстро поняли, что её подход с Zero Block плохо ложился на наш опыт. Команда привыкла мыслить через CSS и компонентную структуру, а не через визуальное позиционирование блоков. 

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

В итоге стало ясно, что единственный способ получить кардинально новый опыт это отказаться от CMS вовсе.

Куда же без AI в 2025

Мы решили попробовать вариант, в котором команда маркетинга сама вайбкодит проект сайта. После обсуждений с фронтенд-командой остановились на следующем стеке: Next.js, Tailwind и shadcn для компонентов. Мы думали, что, возможно, интегрируем сайт с основной частью продукта и будем обмениваться дизайном и компонентами, но забегая вперёд скажу, что решили этого не делать.

Первым шагом нужно было понять, насколько вообще реалистично, что вся команда сможет работать в таком формате. Для этого мы решили начать с небольшого эксперимента. Я поднял шаблон личного сайта с блогом из каталога Next.js. В качестве среды разработки выбрал Cursor, где всегда легко получить доступ к последним моделям.

Разобравшись в базовой структуре Next.js, стало понятно, что по организации страниц он довольно близок к Webflow. По сути это тот же набор вложенных страниц, только описанный в коде. Дальше нас интересовал вопрос замены CMS, и здесь неожиданно хорошо зашёл формат MDX. Он позволял описывать кастомные поля в шапке файла, писать контент в Markdown и при необходимости встраивать JavaScript. На этом этапе серьёзных проблем не возникло.

Сайт у нас был далеко не простым одностраничником. Много анимаций, форм, таблиц. Хотелось сразу проверить, насколько затратно переносить всё это в код и не станет ли поддержка сложнее. Здесь хорошо сработал Tailwind. Он минимизирует влияние каскада и глобальных стилей, снижая риск сложных зависимостей между страницами. Поэтому при изменениях в одном месте сложнее случайно сломать что-то в другом: ты правишь именно то, что ожидаешь. Это особенно важно и для новичков, и для AI.

Чтобы проверить подход на практике, я решил полностью перенести несколько ключевых страниц. Начал со страницы /prices. Процесс выглядел так: я отправлял агенту скриншоты текущей страницы и просил накидать базовую структуру, после чего вручную доводил результат до нужного состояния. Конкретный промпт в этой задаче не имеет большого значения, модели последнего поколения справляются с версткой общей структуры по изображению на ура. Позже стал передавать и куски HTML, чтобы снизить количество галлюцинаций при переносе текста с изображений. 

Для каждой секции страницы я создавал отдельный чат с агентом. Это позволяло не раздувать контекст и параллелить работу сразу с несколькими агентами. Картинки просил просто скачивать с CDN Webflow.

По ходу переноса некоторые вещи хотелось сразу сделать по-новому. Например, довольно быстро удалось встроить navigation menu в шапку — то, до чего в Webflow долго не доходили руки. На базе существующих компонентов собрал поп-ап и форму в модалке. В этот момент стало понятно, что процесс в целом рабочий и масштабируемый.

Как организовали совместную разработку

Разработка ведётся в Git. Мы добавили в репозиторий команду маркетинга, вся работа идёт через pull request. Один человек отвечает за ревью и финальный merge. Этого оказалось достаточно, чтобы удерживать качество и не тормозить процесс.

Всё обучение уложилось в один созвон примерно на полчаса. Самым сложным оказалось разобраться с правами доступа и подключением 2FA. В остальном сценарий был довольно очевидным. Отдельно сильно помог shadcn. За счёт готовых компонентов удалось избежать множества обсуждений о том, как делать базовые вещи.

Cursor.rules как страховка для начинающих

Отдельно помог файл cursor.rules. Формально это просто текстовый файл в репозитори�� со списком правил для AI-агента. По факту он взял на себя часть функций, которые в классической разработке обычно обеспечиваются опытом команды, жёстким ревью и негласными договорённостями.

Мы сознательно переложили часть ответственности за соблюдение правил работы в коде на уровень инструкций для агента. В cursor.rules мы зафиксировали не только стиль кода и архитектурные паттерны, но и правила работы с Git, глобальными файлами и критичными зонами проекта.

Например:

• агенту запрещено коммитить напрямую в main,

• любые изменения возможны только через feature-ветки и pull request,

• перед коммитом обязательно прогоняются линтер, TypeScript и форматирование,

• изменения в глобальных файлах требуют явного подтверждения.

По сути, cursor.rules заменил сразу несколько вещей:

• часть устных правил команды,

• часть документации по проекту,

• и часть защитных механизмов Git, которые обычно держатся на опыте разработчиков.

Для нетехнической команды это оказалось критично. Вместо того чтобы объяснять, почему нельзя править globals.css или tailwind.config.ts, мы зашили это в правила. Агент просто не идёт дальше без подтверждения и явно предупреждает о последствиях.

Отдельно важно, что правила касались не только кода, но и продукта. Например, в них были зафиксированы требования к SEO, семантике HTML, структуре MDX-файлов и метаданным страниц. Это позволило держать единый стандарт без ручного контроля каждой правки.

В итоге cursor.rules стал своеобразным «контрактом» между проектом, агентом и командой. Он не отменяет ревью и CI, но заметно снижает количество ошибок ещё до того, как код попадает в pull request.

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

В итоге путь от мерджа до прода занимает чуть больше трех минут и не требует ручных действий.

Выводы

Плюсы

Сложное стало проще.
Неожиданно, но быстрее всего начали делаться именно “сложные” вещи. Например, баннер про cookies или серия анимаций, которые в Webflow требовали большого количества прокликиваний и времени д��лались за одно обращение к агенту. 

Больше свободы и предсказуемости.
Ограничений конструктора больше нет, а поведение страниц проще контролировать через код и ревью.

Параллельная работа без узких мест.
В Webflow параллелить изменения было сложно из-за ограничений редактора. В Git это решается нормально через ветки и PR.

Меньше зависимости от дизайнеров.
Команда маркетинга может сама собирать секции и страницы из компонентов без постоянного участия продуктовой команды.

Минусы

Мелкие правки стали чуть дороже.
То, что раньше можно было поправить в интерфейсе за минуту, теперь чаще требует PR, проверки и деплоя.

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

Безопасность
Вам самим нужно думать о безопасности, вовремя обновлять библиотеки (за время разработки два раза взломали next.js) знать что такое xss и csp

Техдолг
Без хороших практик чистки вайбкода, проект захламляется лишними файлами, разрозненными решениями похожих задач и оверинженирингом. Тут нам самим еще предстоит развиваться. Не зря Vibe Code Cleanup Specialist уже гуглится)

И да, теперь сайт можно “положить” уже своими руками, без помощи Webflow. Это и плюс, и ответственность.

Немного цифр

Участвовало в переносе: 7 человек
Общее время на миграцию: 2 месяца, параллельно с основной работой
Оценка при фокусе одного человека: около 2 недель

Экономика до: Webflow — $800 / мес
Экономика во время переезда: Cursor — около $500 / мес
Экономика после: около $100 / мес на поддержку и обновления

Хостинг организовали на одном из существующих серверов в Selectel, поэтому дополнительных инфраструктурных затрат не появилось.

Ближайшие планы

Пересобрать страницу обновлений и сделать её интерактивной.
Раньше после выхода обновлений мы показывали модалку внутри приложения через webview страницы обновлений. Из-за ограничений Webflow мы не могли нормально использовать ссылки и интерактив. Теперь хотим переосмыслить формат и сделать обновления более удобными и “живыми”.

Разобраться со статикой
Сейчас сделали без CDN, надо улучшать.

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

Кому такой подход подойдёт, а кому нет

Подойдёт, если:

• есть доступ к технической команде, для консультирования

• у вас большой контентный сайт, блог или база знаний, которые постоянно обновляются;

• маркетинг активно участвуют в работе с сайтом;

• вы готовы инвестировать время в первоначальную настройку стека и правил.

Скорее не подойдёт, если:

• сайт небольшой и редко меняется;

• все правки делает команда маркетинга через CMS;

• нет ресурса на поддержку даже минимального git-процесса;

• важна возможность править контент прямо в визуальном редакторе без PR и ревью.

Для нас этот подход оказался удачным компромиссом между свободой кода и удобством конструктора, но без отката к ручному сопровождению сайта фронтенд-командой.

(1) На самом деле не совсем маркетинга. В компании у нас всего две команды. Продукт отвечает за разработку и дизайн, а команда успеха параллельно ведёт маркетинг, продажи, поддержку и часть продуктовых задач.