Потолок конструктора: когда бизнесу пора уходить с Tilda и Битрикса на своё веб-приложение
Конструкторы сайтов решают ровно ту задачу, для которой созданы: быстро и дёшево собрать витрину, лендинг или простой магазин без программиста. Пока бизнес живёт внутри этой задачи, уходить с конструктора незачем — своя разработка будет дороже и медленнее, а выигрыша не даст.
Проблема начинается, когда компания эту границу проходит и не замечает. Сайт остаётся тем же, а задачи вокруг него меняются: появляются роли и права доступа, нестандартный расчёт стоимости, обмен данными с учётной системой, десятки тысяч позиций в каталоге. Каждая новая потребность закрывается очередной надстройкой, и в какой-то момент бизнес обнаруживает, что платит за поддержку конструкции больше, чем стоила бы своя система.
Разбираем, по каким признакам видно, что потолок достигнут, как посчитать переход на собственное веб-приложение в деньгах, что переносится, а что придётся делать заново, и — главное — как не потерять при переезде поисковый трафик.
Коротко
- Конструктор перестаёт быть дешёвым в тот момент, когда доработки начинают требовать программиста.
- Шесть признаков потолка: хрупкие сторонние вставки, отсутствие ролевой модели, костыльная интеграция с 1С, деградация скорости на большом каталоге, невозможность нестандартной логики, стоимость доработок выше стоимости своей разработки.
- На горизонте одного года конструктор почти всегда дешевле. Считать нужно на три года.
- Главный риск переезда — не бюджет, а потеря поисковых позиций. Он снимается картой редиректов.
- Уходить целиком не обязательно: часто выгоднее оставить витрину на конструкторе и вынести в кастом только рабочую часть.
Шесть признаков, что потолок достигнут
1. Доработки живут на сторонних вставках, которые периодически ломаются. Нужного блока в платформе нет, и его делают вставкой кода — виджетом, скриптом, внешним сервисом. Работает, пока платформа не выкатит обновление. После обновления вставка отваливается, и никто заранее не знает, какая именно. Если у вас накопилось больше пяти таких вставок и вы боитесь обновлений — это уже не сайт на конструкторе, это неподдерживаемая система.
2. Появились роли и права доступа. Конструкторы рассчитаны на две сущности: посетитель и администратор. Как только бизнесу нужно, чтобы менеджер видел свои заявки, а руководитель — все; чтобы клиент видел только свои документы, а подрядчик — только назначенные ему заказы, начинается имитация ролевой модели через отдельные страницы и пароли. Это не масштабируется и небезопасно.
3. Интеграция с учётной системой держится на промежуточных сервисах. Обмен с 1С или CRM идёт через цепочку из коннектора, таблицы и сервиса автоматизации. Данные приходят с задержкой, иногда дублируются, иногда теряются. Разобраться, на каком звене сломалось, может только человек, который эту цепочку собирал.
4. Скорость падает на объёме. Каталог вырос до нескольких тысяч позиций, добавились фильтры — и страницы начали открываться заметно дольше. На конструкторе это лечится в основном сокращением того, что показываете. Своя система решает это индексами, кешированием и отдельным поисковым движком.
5. Нужна логика, которой в платформе нет в принципе. Расчёт по нелинейной формуле, многошаговый конфигуратор с зависимыми параметрами, персональные цены для разных групп клиентов, сложные сценарии оформления. Каждый такой запрос упирается в один ответ: «средствами платформы не реализуется».
6. Арифметика перевернулась. Самый надёжный признак. Посчитайте, сколько за последний год ушло на доработки, подключение сторонних сервисов и работу фрилансеров, которые всё это чинят. Если получившаяся сумма сопоставима с бюджетом небольшого веб-приложения, вы уже платите за кастомную разработку — просто по частям и без результата в виде собственной системы.
Арифметика перехода
Сравнивать разовый бюджет разработки с месячной подпиской бессмысленно. Считать надо совокупную стоимость владения на одинаковом горизонте — три года это разумный минимум, потому что за меньший срок кастом не успевает окупиться.
Что входит в стоимость конструктора:
- подписка на платформу, включая платные тарифы за нужные функции;
- сторонние сервисы: коннекторы к учётной системе, виджеты, формы, чаты, аналитика;
- работа исполнителей на доработки и починку вставок после обновлений платформы;
- скрытая часть — упущенное из-за ограничений интерфейса. Если конверсия просела на процент, потому что нужный сценарий не получилось реализовать, это тоже деньги.
Что входит в стоимость своей разработки:
- аналитика и проектирование;
- дизайн и разработка;
- серверная инфраструктура — ежемесячный платёж, которого на конструкторе не было;
- поддержка и развитие — ориентировочно 15–25% от бюджета разработки в год.
Порядок сумм по рынку заказной разработки в 2026 году: простое веб-приложение начинается примерно от 500 тысяч рублей, личный кабинет или сервис среднего размера — от полутора миллионов, корпоративная система с интеграциями — от трёх миллионов и выше.
Честный вывод из этой арифметики: на горизонте одного года конструктор выигрывает почти всегда. Переход оправдан не экономией на подписке, а тем, что снимает ограничения, которые уже мешают бизнесу зарабатывать. Если ограничения не мешают — оставайтесь.
Что переносится, а что придётся делать заново
Что
Переносится
Комментарий
Тексты, изображения, статьи
Да
Выгружаются и импортируются, ручная работа минимальна
Каталог товаров и услуг
Да
Через выгрузку в структурированный формат
База клиентов и заявок
Да, но с проверкой
Часто хранится в разных местах: часть на платформе, часть в CRM, часть в почте
История заказов
Обычно да
Зависит от того, была ли она вообще в системе, а не в таблицах
Поисковые позиции
Да, при правильном переезде
Основной риск проекта, разбираем ниже
Дизайн
Нет
Макеты конструктора не переносятся в код, дизайн делается заново
Интеграции
Нет
Собираются заново, обычно нормально — старые и были проблемой
Аналитика и накопленная статистика
Частично
Счётчики переносятся, исторические данные внутри платформы — нет
Отдельно про базу клиентов. Перед переездом стоит выяснить, где реально лежат данные и в каком виде их можно забрать. Иногда выясняется, что часть информации существует только внутри интерфейса платформы и выгружается в неудобном формате или не выгружается вовсе. Это выясняют до старта работ, а не в день переключения.
Как не потерять поисковый трафик
Это самая дорогая ошибка при переезде, и она полностью предотвратима. Порядок действий:
1. Снимите полный список адресов до начала работ. Выгрузите все страницы, которые есть в индексе поисковых систем, вместе с трафиком по каждой. Так вы увидите, какие страницы действительно важны, а какие можно не сохранять.
2. Составьте карту соответствий. Для каждого старого адреса — новый. Если структура меняется, каждый старый адрес должен вести на релевантную новую страницу, а не на главную. Массовый редирект всего на главную поисковые системы трактуют как потерю страницы.
3. Настройте постоянные редиректы. Именно постоянные, а не временные: временный редирект сообщает поиску, что переезд не окончательный, и старый адрес остаётся в индексе.
4. Сохраните метаданные и заголовки. Если страница ранжировалась, её title и структура заголовков работали. Менять их одновременно с переездом — значит смешать два фактора и не понять потом, что повлияло.
5. Не переключайтесь в пик сезона. Просадка на две-четыре недели после переезда — нормальное явление, поисковым системам нужно время на переобход. Планируйте переключение на низкий сезон.
6. Первые две недели держите под наблюдением. Отправьте новую карту сайта, следите за ошибками обхода, за страницами, выпавшими из индекса, и за динамикой позиций по ключевым запросам. Большинство проблем всплывает в первые десять дней и лечится за час, если их заметили.
Ещё один практический совет: не удаляйте старый сайт сразу. Пусть он полежит доступным хотя бы месяц — на случай, если что-то не перенеслось и это обнаружится позже.
Гибридный вариант, о котором редко думают
Переход не обязан быть переходом «всего». Часто оптимальное решение — разделить продукт по назначению:
- витрина остаётся на конструкторе — лендинги, промостраницы, блог, всё, что маркетинг меняет еженедельно и не хочет ждать разработчиков;
- в собственную разработку выносится рабочая часть — личный кабинет, расчётный модуль, интеграция с учётной системой, всё, что требует логики и ролей.
Что это даёт: маркетинг сохраняет свободу и скорость, а бизнес-логика перестаёт зависеть от ограничений платформы. Бюджет меньше, чем при полном переписывании, а самые болезненные ограничения снимаются сразу.
Технически это решается общей авторизацией и единым доменом с разными разделами. Пользователь не замечает, что находится в двух разных системах.
Гибрид особенно уместен, когда сайт хорошо ранжируется. Вы не трогаете то, что приносит трафик, и не создаёте себе риск просадки на ровном месте.
Когда уходить с конструктора не надо
- Всё работает, и жалоб нет. Отсутствие ограничений — не повод искать более технологичное решение. Уход с конструктора решает проблемы, а не создаёт статус.
- Задача сводится к «хочется красивее». Это редизайн, и на конструкторе он делается быстрее и дешевле.
- Бизнес сезонный, и вне сезона сайт почти не нужен. Стоимость владения своей системой равномерна весь год, а конструктор можно перевести на минимальный тариф.
- Нет человека, который будет отвечать за продукт. Собственное веб-приложение требует владельца на стороне бизнеса. Без него система через год превратится в такой же неподдерживаемый набор костылей, только дороже.
- Ограничения не в платформе, а в процессах. Если заявки теряются, потому что их некому обрабатывать, новый личный кабинет ничего не изменит.
FAQ
Сколько занимает переход? Простое веб-приложение — два-три месяца, личный кабинет с интеграциями — четыре-шесть. Плюс время на подготовку: выгрузку данных и составление карты редиректов лучше делать заранее, параллельно с разработкой.
Можно ли переехать без потери позиций? Полностью без просадки — редко. Нормальный результат — временное снижение на две-четыре недели с последующим возвратом. Если через два месяца позиции не восстановились, значит, редиректы или структура настроены неверно.
Что делать, если сайт на конструкторе хорошо ранжируется? Рассмотреть гибрид: оставить ранжирующиеся страницы как есть, а новую функциональность собрать отдельно. Рисковать работающим источником трафика ради технологической однородности не стоит.
Обязательно ли делать дизайн заново? Да. Макеты конструктора собраны из его блоков и в код не переносятся. Но существующий сайт — хороший исходник: структура и логика уже проверены пользователями, их можно взять за основу и не проектировать с нуля.
Останется ли возможность самим менять контент? Да, если это заложено в проект. Собственная система тоже получает административную панель, просто она делается под ваши сущности, а не универсальная. Этот пункт нужно проговорить с подрядчиком на старте — иначе легко получить продукт, где любое изменение текста требует разработчика.
Что если бюджета на полноценную разработку нет? Начните с одного модуля, который приносит больше всего боли, и оставьте остальное как есть. Веб-приложение можно наращивать по частям — в отличие от конструктора, где расширение упирается в границы платформы.