Конструктор выигрывает, когда нужен быстрый запуск страницы. Свой продукт нужен, когда на коде держится процесс: кабинет, роли, расчёты, интеграции.
Запустить страницу сегодня можно за дни: Tilda, Webflow, Readymag и похожие платформы закрывают лендинг, промо и простую витрину. Рядом с этим остаются задачи, которые платформа не вытягивает без костылей: личные кабинеты, нестандартная логика, обмен с 1С, нагрузка, свой сценарий, которого нет в блоках.
В MakeDifference этот вопрос звучит почти на каждой первой встрече: «Нам точно писать своё?» Ответ зависит не от моды на код, а от того, что именно должно работать через год. Ниже — рабочие критерии, которыми мы пользуемся сами.
Чем конструктор отличается от своей разработки
Конструктор — платформа с готовыми блоками. Вы собираете страницу или небольшой магазин в рамках её модели. Код иногда можно дописать, но потолок задаёт платформа: данные, роли, скорость, SEO-настройки и интеграции живут так, как их задумал вендор.
Своя разработка — продукт под вашу логику. Стек может быть разным, для веба мы чаще собираем современный фронтенд и отдельный сервер. Важно другое: структура данных, права, интеграции и интерфейс принадлежат вам. Потолок сдвигается вместе с задачей, а не вместе с тарифом конструктора.
Это не спор «дёшево против дорого». Это выбор инструмента. Лендинг на платформе часто дешевле и быстрее. Сервис, который должен жить и обрастать функциями, на длинной дистанции дешевле не переписывать с конструктора.
Когда конструктор — правильный выбор
- Нужно проверить спрос: одна страница, оффер, форма, аналитика. Срок часто измеряется днями, а не месяцами.
- Сайт рассказывает о компании и почти не содержит логики. Портфолио, промо акции, визитка направления.
- Запуск рекламы уже на этой неделе, а своего продукта ещё нет.
- Интеграции ограничиваются формой, почтой, метрикой и простой передачей лида в CRM.
Плюсы честные: скорость, предсказуемая подписка, правка текстов без разработчика. Ограничения тоже честные. Вы зависите от возможностей платформы. Сложный интерфейс, нестандартные состояния и тяжёлая логика начинают упираться в блоки. Когда проект вырастает, перенос на свой стек всё равно случается — уже с живыми клиентами и ценой простоя.
Когда платформа начинает мешать
Пора смотреть в сторону веб-приложения, если появляется хотя бы один из признаков.
- Нужны кабинеты и роли. Клиент, сотрудник, партнёр, администратор видят разное. Конструкторы дают заготовки кабинетов, но поля и отчёты остаются теми, которые предусмотрел вендор.
- Есть расчёт, а не страница. Скидки по правилам, слоты, остатки, согласования, документы, отчёты.
- Сценарий ваш, а не «как у всех». Платформа сопротивляется: ломается вёрстка, не хватает состояний, автоматизация собирается из трёх виджетов.
- Нужны интеграции. 1С, склад, биллинг, внутренние API, государственные сервисы. На конструкторе это либо нельзя, либо хрупко.
- Продукт должен расти. Новые модули, нагрузка, отдельные команды. Шаблон не становится архитектурой от того, что в него дописали скрипт.
Сюда же относятся сервисы, где сам продукт и есть бизнес: маркетплейс, платформа обучения, внутренний портал, инструмент с ИИ, финансовый кабинет. Для таких задач стартовый ориентир своей разработки — от 450 000 ₽ и от полутора месяцев. Интерфейс можно спроектировать раньше кода, от 150 000 ₽ и от двух недель.
Как не платить дважды
Развилка «сразу большой код» или «сначала конструктор, потом всё выбросить» — ложная. Между ними есть рабочие ходы.
Прототип до кода. Структура экранов и кликабельный макет показывают путь клиента раньше, чем вы оплатите сервер. На этом этапе дешево менять логику. Как устроен наш дизайн-процесс — в статье про проектирование интерфейса.
Короткий MVP на своей архитектуре. В первой версии только сценарий, без которого гипотезу не проверить. Фундамент уже ваш: пользователи, данные, интеграции не придётся переносить с платформы. Вы платите за ядро, а не за временный сайт и потом за тот же сайт ещё раз.
Этапы. Сначала сценарий и интерфейс, затем каркас, затем бизнес-логика. Рабочий кусок появляется рано, следующие куски не переписывают предыдущие. Формат договора под это — фикс на понятный объём или часы, если объём ещё плавает. Подробнее в материале про формат работы.
Разбор до старта. Если непонятно, конструктор выдержит или нет, мы разбираем процессы, интеграции и риски и говорим прямо. Иногда честный ответ — остаться на Tilda. Это тоже результат.
Как выбрать за четыре вопроса
- Что вы запускаете? Страница о компании — конструктор. Сервис, которым пользуются повторно, — свой продукт.
- Функции будут добавляться каждый месяц? Если нет, платформа уместна. Если да, закладывайте свой фундамент.
- Есть расчёты, роли, документы, обмен с другими системами? Это территория разработки.
- Дата кампании уже завтра? Конструктор. Можно спланировать месяц–полтора — есть смысл собирать своё.
Гибрид тоже нормален. Конструктор приводит рекламный трафик, а кабинет и интеграции живут отдельным приложением. Плохой гибрид — когда в конструктор начинают «докручивать» учётную систему.
Частые вопросы
Что дешевле?
На старте дешевле конструктор: подписка и сборка страницы. На дистанции в несколько лет дешевле свой продукт, если он развивается. Перенос живого кабинета с платформы почти всегда дороже, чем сразу сделать узкое ядро.
Можно ли сделать нестандартную логику на конструкторе?
Иногда точечно, ценой хрупких обходных путей. Как только логика становится преимуществом бизнеса, поддержка этих путей съедает выигрыш в скорости. Для такой логики нужен свой код.
Подходит ли конструктор серьёзной компании?
Да, если сайт — витрина. Нет, если на нём держится операция: заявки с правилами, кабинеты, производство документов, личный состав. Витрину и систему можно развести по разным инструментам.
Как быстро запускается первая версия своего продукта?
Зависит от сценария. Ориентир веб-приложения на сайте — от полутора месяцев. Узкий MVP с одним главным путём пользователя часто укладывается в этот коридор. Срок называем после разбора, а не по средней температуре проектов.
Кто будет править продукт потом?
После запуска остаётся инструкция, доступы и гарантия от 2 месяцев на сделанный функционал. Дальше — сопровождение по часам, если продукт живёт. Это нормальный режим, а не признак того, что «релиз сырой».
Что сделать дальше
Опишите, что должен сделать пользователь и с какими системами продукт обязан говорить. Мы скажем, хватает ли конструктора или пора закладывать своё, и не будем продавать разработку там, где достаточно страницы.
