Конструктор подходит, когда выбранная платформа на нужном тарифе закрывает обязательные задачи сайта, сотрудникам удобно с ней работать, а зависимость от сервиса приемлема для бизнеса. Индивидуальная разработка становится обоснованной, когда проверенные возможности платформы не покрывают важный процесс или компании нужен контроль над данными, размещением и развитием, который она готова поддерживать.
Решение нельзя принять по одной цене подписки, красивому шаблону или обещанию «потом всё перенесём». До выбора полезно проверить пять вещей: как устроен контент, что реально делает интеграция, что можно выгрузить, у кого находятся доступы и какие расходы останутся после запуска. Ниже — способ провести такую проверку и несколько учебных ситуаций с разными решениями.
Сначала определите, что именно вы выбираете
Конструктор, шаблон и индивидуальный дизайн — разные характеристики. На платформе можно создать авторское оформление; сайт на собственном коде может использовать типовую сетку. Внешняя уникальность сама по себе не говорит, где хранятся данные, кто обновляет сервер и можно ли сменить поставщика.
В этой статье под конструктором понимается сервис, в котором компания собирает и редактирует сайт средствами платформы. Под индивидуальной разработкой — проект, чья структура, функции и программная реализация создаются под согласованную задачу. Конкретные инструменты и условия размещения нужно уточнять в предложении исполнителя.
Поэтому вопрос «Тильда или собственный сайт?» лучше раскрыть: нужен собственный домен, возможность редактировать материалы, размещение на своём сервере или управляемая компанией программная система? Это разные требования. Выбор между готовой CMS и фреймворком разобран отдельно в статье об основе сайта. Здесь оценим границы платформы до того, как бизнес вложится в неё.
Проверьте возможности на материалах своего бизнеса
Контент: сможет ли сотрудник поддерживать сайт без ручного дублирования
Просите показать работу с тем, что вы действительно будете публиковать. Для услуги это описание, варианты и условия обращения. Для каталога — характеристики и категории. Для редакции — статьи, авторы, рубрики и связанные материалы.
Создайте пробный набор материалов, содержащий обычный случай и исключение: например, услугу с несколькими вариантами или статью с галереей и длинным названием. Затем предложите будущему редактору поменять данные. Где он это делает? Надо ли искать одинаковый текст на нескольких страницах? Можно ли обновить повторяющуюся информацию в одном месте? Что произойдёт при добавлении нового материала?
Различайте возможность нарисовать карточку и возможность управлять записями с отдельными полями. Ручная сборка каждой страницы может устраивать небольшую витрину. Для регулярно пополняемой базы материалов та же работа становится постоянной нагрузкой на сотрудников.
Не следует утверждать, что конструкторы умеют только статические страницы. Например, в Tilda есть настраиваемые CMS Потоки: можно менять набор полей и связывать отображение с содержимым записей. В документации обычных Потоков описаны экспорт и импорт постов через CSV и лимит в 5 000 постов в одном потоке. Это конкретные возможности конкретного модуля, а не подтверждение пригодности для любой редакционной задачи.
Для выбора важны не только лимиты. Проверьте нужные связи, поиск, адреса страниц, массовые изменения и порядок публикации. Если критичная операция неудобна, попросите оценить, сколько ручных действий потребуется при вашем объёме обновлений. Зафиксируйте, что проверено, а что пока обещано.
Интеграции: пройдёт ли весь процесс, включая сбой
Название CRM в списке подключений ещё не описывает результат. Интеграция может передавать только новую заявку, а вашему бизнесу нужны также изменение заказа, обратная передача статуса или актуальные остатки. Для каждого направления сформулируйте: какие данные отправляются, когда это происходит, какая система считается источником правильного значения и кто разбирает ошибки.
Есть разные способы подключения:
- Готовая интеграция закрывает предусмотренный поставщиком сценарий. Нужно проверить поддерживаемые поля, события и ограничения.
- Webhook отправляет сведения на указанный обработчик при событии. Приём, проверку и дальнейшую работу с данными должен выполнять этот обработчик.
- Собственный промежуточный сервис связывает системы по вашим правилам. Он требует разработки, размещения и поддержки даже при использовании конструктора.
У Tilda, например, есть отправка данных форм через Webhook. Документация требует HTTPS и ответ обработчика в течение пяти секунд; при неудаче предусмотрены ещё две попытки с интервалом в минуту. Из этого следует практическое требование к проекту: получатель должен учитывать повторную доставку, а команда — иметь способ обнаружить заявку, которая не дошла после завершения попыток. Способ учёта повторов и обработки ошибок нужно согласовать с разработчиком.
Проверяйте интеграцию на тестовых данных: обычное обращение, повторная доставка, недоступность принимающей системы и восстановление её работы. Результат должен быть понятен менеджеру: где найти обращение, как убедиться, что оно обработано, и к кому обратиться при сбое. Если на демонстрации показывают только письмо после заполнения формы, обратный обмен с CRM ещё не проверен.
Индивидуальная разработка позволяет реализовать согласованные правила обмена, но не отменяет ограничений чужого API, тарифов CRM и качества исходных данных. Ответственность за каждое звено нужно определить при любом варианте.
Разделите экспорт файлов, данных и работающих функций
Слово «экспорт» может означать несколько разных результатов. Получить страницы для размещения на сервере, выгрузить содержимое каталога и перенести весь рабочий процесс — три отдельные задачи.
Файлы сайта позволяют воспроизвести внешний вид и доступные в них действия. Данные — это материалы, записи и связи, которые новой системе нужно прочитать и сохранить. Работающие функции включают редактирование, приём обращений, доступ пользователей, расчёты и обмен с другими системами. Наличие архива с первой частью не подтверждает перенос двух остальных.
Разницу хорошо видно на официальных правилах двух платформ:
| Платформа | Что подтверждает документация | Что это означает для решения |
|---|---|---|
| Tilda | Экспорт страниц доступен на линейке Business. Tilda CRM и личный кабинет не экспортируются; панели управления Потоками и Каталогом остаются внутри Tilda. Для отправки форм через сервисы приёма данных после экспорта нужна активная подписка | Размещение страниц на другом сервере ещё не делает проект независимым от платформы. Нужно отдельно решить судьбу каждого используемого модуля |
| Wix | Сайт должен размещаться и работать на серверах Wix; внешнее размещение готового сайта не поддерживается архитектурой сервиса | Для смены платформы планируют сборку сайта в новой системе и перенос доступных материалов, а не установку готового сайта на другой хостинг |
Сведения об ограничениях приведены в официальных справках Tilda и Wix. Документы проверены 3 октября 2026 года. Это сравнение переносимости; оно не оценивает остальные возможности Wix и не заменяет проверку выбранной платформы перед договором.
CSV-выгрузка постов Tilda не противоречит тому, что панель управления Потоками не экспортируется. Выгрузка даёт данные для следующей системы, а панель и механизм публикации нужно обеспечить отдельно. Именно такое различие полезно искать в документах любого сервиса.
До оплаты запросите небольшой пробный экспорт: текст, изображения, адреса, метаданные и нужные поля. Попросите принимающего разработчика открыть его и объяснить, какие сведения можно импортировать, что придётся преобразовывать и что потеряется. Уточните, выгружаются ли сами изображения или только ссылки на них, и как сохранить файлы, если старый сервис перестанет быть доступен.
Для проекта на собственном коде задайте аналогичные вопросы. Сможет ли другая команда развернуть его из переданного репозитория? Есть ли резервная копия данных, инструкции и перечень внешних сервисов? Если всё работает только на сервере прежнего исполнителя без понятного порядка восстановления, смена подрядчика тоже может потребовать значительных работ.
Уточните, чем компания сможет управлять сама
Право использовать результат, контроль учётных записей и техническая возможность переноса — отдельные вопросы. Не делайте юридических выводов по наличию кнопки экспорта: условия использования платформы, договор с исполнителем и лицензии материалов нужно проверить отдельно.
Для ежедневной работы важно, чтобы ответственный сотрудник компании контролировал основной аккаунт и восстановление доступа. Подрядчику лучше выдавать отдельный доступ с необходимыми полномочиями. Общий пароль делает сложнее отключение одного человека и разделение ответственности.
Платформа может поддерживать разные роли. У Tilda мультидоступ сотрудников — платная услуга; есть полный и ограниченный доступ. Экспортировать или удалить весь проект может только владелец аккаунта. Значит, доступ редактора сам по себе не подтверждает, что компания сможет забрать проект или управлять им после смены исполнителя.
Проверьте на тестовом аккаунте, что редактор выполняет свои задачи и не может совершить запрещённое ему действие. Отдельно выясните, кто управляет доменом, оплатой сервисов, аналитикой и подключённой CRM. Требования к доступам нужно включить и в бюджет: дополнительные участники команды могут оплачиваться отдельно.
Для индивидуальной разработки к этим вопросам добавляются репозиторий, сервер, резервные копии и процедура выпуска изменений. Передача кода не назначает автоматически ответственного за обновления и восстановление. Состав результата подробнее разобран в материале о передаче сайта клиенту.
Сравните расходы после запуска на одинаковых условиях
Сравнение «подписка против цены разработки» неполно: в первом случае названа регулярная плата за платформу, во втором — разовая работа над проектом. Для обоих предложений задайте одинаковый период использования, состав функций и объём предполагаемых изменений.
В расчёт стоит включить:
- Создание и запуск: структура, дизайн, настройка или программирование, наполнение, подключение сервисов и проверка.
- Регулярные платежи: платформа либо хостинг, домен, нужные внешние сервисы, дополнительные роли и модули.
- Работу команды: обновление материалов, обработку ошибок интеграции, плановые изменения и техническую поддержку.
- Рост в пределах известного плана: новые материалы, пользователи или процессы, для которых может понадобиться другой тариф либо доработка.
- Возможный выход: выгрузку, преобразование данных, перенос функций и проверку нового сайта, если выбранный сервис перестанет подходить.
Попросите отдельно указать, что включено в регулярный платёж и что оплачивается по запросу. Для платформы проверьте условия продления, остановки оплаты и нужные функции тарифа. Для собственного проекта — кто выполняет обновления, хранит копии, наблюдает за ошибками и восстанавливает сайт. Наличие сервера не выполняет эти работы само по себе.
Не включайте миграцию как неизбежный расход, если оснований для неё пока нет. Оформите её отдельным сценарием: при каком известном изменении бизнеса она понадобится и какие работы потребует. Так можно сравнить приемлемый риск с затратами на более сложную систему сейчас. Без состава сайта и проверки выгрузок достоверную стоимость переноса назвать нельзя.
Три задачи, для которых решения будут разными
Следующие примеры учебные. Они показывают ход выбора, а не описывают клиентов Студии Вебирус.
Сезонная услуга: конструктор может закрыть задачу целиком
Компания предлагает обслуживание оборудования к началу сезона. Сайт объясняет состав услуги, географию и порядок обращения; форма передаёт контакт и описание задачи менеджеру. У компании нет собственного расчёта цены на сайте и отдельного кабинета клиента.
Если проверены редактирование, мобильное отображение и доставка обращений, а условия тарифа и зависимость от сервиса устраивают компанию, конструктор — обоснованный вариант. Индивидуальное оформление можно делать в пределах его возможностей. Собственный код только ради необычной композиции не решает дополнительной бизнес-задачи.
Границу решения стоит записать заранее: например, появление обязательной онлайн-диагностики с расчётом по внутренним правилам потребует новой оценки. Сам по себе запуск ещё одной услуги не означает, что пора менять платформу.
Регулярные публикации: сначала проверьте редакционную работу
Компания развивает базу инструкций. Материалы имеют рубрики, автора, связанные документы и обновляемые сведения. Редактор добавляет записи регулярно, а некоторые данные повторяются в разных публикациях.
Здесь нельзя принять решение по обложке одного поста. Нужны пробный набор материалов, проверка структуры полей, связей, массовых правок и экспорта. Если выбранная платформа закрывает эту работу, конструктор остаётся вариантом. Если обязательные связи приходится постоянно поддерживать вручную, разумно оценить систему с подходящей моделью контента. Это может быть готовая CMS: задача ещё не доказывает необходимость индивидуальной разработки.
В предложении исполнителя важно видеть способ работы редактора и ограничения, а не только обещание добавить блог. Пробный импорт в другую систему позволит оценить переносимость материалов до того, как накопится большая база.
Кабинет дилера: собственная логика должна быть подтверждённой потребностью
Поставщику нужен кабинет, в котором разные организации видят свои цены и документы, заказ проходит согласование, а состояние заказа приходит из учётной системы. Здесь обязательны проверка полномочий каждого пользователя, согласованные правила цен и обработка сбоев обмена.
Сначала проверьте, нет ли готового сервиса или модуля, который поддерживает именно этот процесс. Если у рассматриваемой платформы нет нужных прав, событий обмена или правил заказа, индивидуальная разработка становится обоснованной. Проверке подлежит весь процесс: скрыть кнопку в интерфейсе недостаточно для ограничения доступа к чужому заказу.
Возможен и разделённый вариант: публичные страницы услуг остаются на конструкторе, а кабинет работает как отдельная система. Он полезен, если маркетинговый контент и операции действительно самостоятельны. При этом появляются дополнительные задачи: переход пользователя между частями, согласованное оформление, аналитика и поддержка двух решений. Такой вариант нужно оценивать целиком.
Если рассматривается разработка сайта на Laravel, передавайте исполнителю правила доступа и заказа, данные и требования к обмену. Название технологии не заменяет эту работу и само по себе не подтверждает преимущества перед проверенным готовым сервисом.
Из чего складывается цена миграции
Миграция — проект по восстановлению нужного результата в другой системе. Цена зависит от того, что уже накоплено и сколько поведения остаётся привязано к старой платформе. Помимо количества страниц, имеют значение структура записей, связи, внешний код и используемые модули.
Для оценки попросите разложить работы:
- Инвентаризация. Какие страницы, материалы, формы, пользователи и подключения есть сейчас; что переносится, что сохраняется во внешней системе, от чего компания отказывается.
- Получение и подготовка данных. Какие выгрузки доступны, хватает ли полей, как сохранить изображения и связи, что потребует ручной очистки.
- Сборка новой версии. Шаблоны, редактор, права, функции и интеграции, которых нет в готовом экспортированном результате.
- Сохранение адресов и настройка переходов. По возможности оставляют прежние URL. Если они меняются, составляют соответствие старых и новых адресов и настраивают постоянные перенаправления на подходящие страницы.
- Проверка и переключение. Сверяют данные и сценарии, переносят изменения, появившиеся после пробной выгрузки, проверяют обращения и заказы, затем переключают домен по согласованному плану.
- Период после переключения. Проверяют ошибки и индексацию, сохраняют необходимые копии и возможность исправления. До отключения старого сервиса убеждаются, что новая версия работает без оставшихся зависимостей от него.
В руководстве Google по переезду сайта при смене адресов рекомендуются карта URL, постоянные серверные перенаправления, обновление внутренних ссылок и контроль после переезда. В документации также указана возможность временных колебаний видимости в поиске. Поэтому обещать перенос «без влияния на SEO» заранее некорректно.
В бюджет перехода входят и организационные затраты: обучение редакторов, время ответственных сотрудников и, когда оно требуется планом, одновременная оплата старого и нового размещения. По пробной выгрузке и инвентаризации можно оценить работы. Без них фиксированная сумма будет отражать предположения, которые надо явно перечислить.
Что зафиксировать перед окончательным выбором
Подготовьте короткую запись решения, которую поймут владелец бизнеса, редактор и разработчик:
- обязательные сценарии и подтверждение, что они работают на выбранном варианте;
- ограничения платформы, с которыми компания согласна;
- состав стартовых работ и регулярных расходов;
- ответственных за аккаунты, материалы, интеграции и восстановление;
- доступные выгрузки и событие, при котором понадобится пересмотреть решение.
При обсуждении разработки сайта под ключ эта запись поможет сравнить предложения по одному результату. Выбирать стоит вариант, который закрывает проверенные потребности и оставляет компании понятные обязанности и путь дальнейшего развития. Для простого сайта это может быть конструктор; для процесса с собственными правилами — индивидуальная система; для части задач — готовое решение или сочетание нескольких инструментов.
