Конструктор или разработка: где проходит граница
Четыре проекта по обе стороны границы: лендинг за 4 недели и каталог на 9 200 позиций с обменом каждые 15 минут. Где конструктора уже не хватает.
Мы делаем сайты на заказ, и это делает нас заинтересованной стороной. Поэтому сразу: примерно каждому четвёртому, кто приходит с запросом на разработку, мы отвечаем, что задача решается конструктором за две недели и 60 000 ₽, и разработка ему не нужна.
Граница между «хватит конструктора» и «нужна разработка» проходит не по числу страниц и не по размеру бюджета. Четыре проекта из нашего списка стоят по обе стороны от неё, и по ним видно, чем она задана на самом деле.
| Проект | Срок | Что решило выбор | Конструктор |
|---|---|---|---|
| Лендинг складского комплекса | 4 нед | Схема комплекса с подсветкой свободных блоков | Почти хватило |
| Сайт бухгалтерского аутсорсинга | 9 нед | 12 страниц под отраслевые запросы и калькулятор | Хватило бы на старте |
| Оптовый каталог электротехники | 16 нед | 9 200 позиций, обмен с 1С каждые 15 минут | Невозможен |
| Редизайн мебельной фабрики | 8 нед | Свои шаблоны на уже работающей структуре | Означал бы переезд |
Где конструктор выигрывает
Одностраничник под рекламу, промо мероприятия, сайт-визитка на десять страниц, простой блог. Всё, где структура не меняется годами, а контент правит один человек. Конструктор даёт срок в две-три недели вместо трёх месяцев, стоимость в десять раз ниже и хостинг, о котором не надо думать.
Отдельно: если проверяется гипотеза и через полгода сайт может быть выброшен, разработка почти всегда лишняя трата. Проверьте спрос на конструкторе, потом приходите с цифрами.
Лендинг склада: случай, где конструктора почти хватило
Лендинг складского комплекса класса A мы собрали за четыре недели. За первый месяц он дал 52 заявки при цене заявки из Директа 2 400 ₽, медианное время до первого действия на странице — 9 секунд. Заявки уходят в Telegram через Bot API: CRM там нет, потому что обращения читает один человек, и заводить под него систему было бы тратой.
Конструктор не подошёл ровно по одной причине. Главный экран — схема комплекса: свободные блоки подсвечиваются по площади и высоте потолка, заявка уходит сразу с номером блока. Это инлайновый SVG, который слушает наведение и клик и знает про занятость каждого блока. Всё остальное на странице конструктор сделал бы не хуже. Если бы вместо схемы был список блоков таблицей, мы бы так и ответили: берите конструктор.
Где он упирается в потолок
Данные из учётной системы
Первое и главное — каталог, который берёт данные из учёта. Оптовый каталог электротехники до нас четвёртый год стоял на конструкторе. Товары заводили руками, поэтому в каталоге лежало 640 позиций из 9 200 складских, а остальное менеджеры отправляли клиентам прайсом в Excel. Остатки обновлялись раз в сутки ночью, и половина заказов приходила на то, чего уже нет.
Вот настоящая цена конструктора на такой задаче: не строка в счёте, а весь склад, кроме 640 позиций, которого на сайте просто нет, и сборка одного заказа менеджером за 14 минут. После переделки остатки и цены приходят из 1С каждые 15 минут, подбор идёт по 12 характеристикам на Typesense, а тот же заказ собирается за 4 минуты. Ни одна из этих частей на конструкторе не воспроизводится: там нет доступа ни к расписанию обмена, ни к поисковому индексу. Из чего складывается такая работа, мы разобрали на странице магазина и каталога.
Скорость и вёрстка
Второе — скорость. Разметка конструктора вкладывает восемь уровней контейнеров и грузит редакторский JavaScript на боевой странице. Довести LCP до полутора секунд там нельзя: доступа к критическому пути отрисовки нет.
На том же каталоге LCP на 4G уехал с 4,2 до 1,4 секунды, и решающая часть работы была не в картинках. Страницы категорий рендерятся на сборке, а цена и остаток догружаются отдельным запросом — на конструкторе оба решения недоступны, потому что сборкой страниц распоряжается платформа. Как считаются такие замеры и что из правок действительно даёт эффект — в разборе Core Web Vitals.
Страницы под запросы потоком
Третье — структура под поиск. Посадочные под фильтры, свои шаблоны заголовков и разметка товара делаются либо ограниченно, либо ценой обходных решений. Если органика — основной канал, потолок упирается в это.
На сайте бухгалтерского аутсорсинга 12 страниц под отраслевые запросы подняли заявки из органики с 7 до 29 в месяц за девять месяцев. Стоимость одной такой страницы — 18 000 ₽ при потоке 12 заявок в месяц. Пока страниц двенадцать, разницы с конструктором почти нет: их можно собрать где угодно. Разница появляется, когда такие страницы нужно выпускать потоком и каждая обязана отличаться не текстом, а шаблоном — своим заголовком, своим набором полей, своей разметкой.
Данные и договор
Четвёртое — персональные данные. Хранение на площадке, которую вы не контролируете, — вопрос к юристу клиента, а не к нам. Иногда ответ юриста и решает выбор, и никакой расчёт стоимости владения его не перевесит.
Переезд, которого можно не делать
Отдельный случай — сайт уже есть, он собирает трафик, и обсуждается, «перебраться на конструктор или переписать». Здесь важно, что переезд сам по себе стоит денег и трафика, а не только времени.
Мебельной фабрике мы сохранили структуру и все адреса, переписали вёрстку и шаблоны карточек: вес страницы упал с 4,2 МБ до 780 КБ, CLS на карточке — с 0,31 до 0,02, позиции через два месяца остались без изменений. Восемь недель работы и ни одного нового адреса. Переезд на другую платформу дал бы примерно тот же прирост скорости плюс риск потерять то, за что сайт уже ранжируется. Это редизайн, а не новый сайт, и считается он по числу шаблонов, которые надо переписать, а не по числу страниц.
Три вопроса до выбора
Первый: откуда берутся данные? Если товары, цены и остатки живут в 1С, CRM или на складе, считайте стоимость обмена сразу, до выбора платформы. Это самая недооценённая часть сметы: на каталоге электротехники обмен занял четыре недели из шестнадцати, и это при том, что данные проверили заранее.
Второй: меняется ли структура сайта чаще раза в квартал? Если да, нужна своя админка, а не набор блоков. Набор блоков хорош, пока набор не приходится расширять под каждую новую задачу.
Третий: что произойдёт, если через два года платформа изменит тарифы или закроется? Если ответ «переделываем всё с нуля», в стоимость конструктора надо честно заложить будущий переезд — вместе с риском для позиций, который на мебельной фабрике мы обошли только потому, что адреса не тронули.
Как считаем на самом деле
Мы складываем стоимость владения за три года: разработка или подписка, доработки, интеграции, работа контент-менеджера, переезд в конце срока. Числа страниц в этом расчёте нет — само по себе оно не решает ничего. Граница у нас проходит по трём признакам, и достаточно любого одного:
- данные приходят из учётной системы по расписанию, а не заводятся руками;
- страницы под запросы выпускаются потоком, и каждая отличается шаблоном, а не только текстом;
- на странице есть свой интерфейс — калькулятор, схема, подбор по характеристикам, — который считает или показывает данные.
По эту сторону границы конструктор дешевле почти всегда. По другую разработка окупается за первый год, и считать надо не подписку, а потери: 640 позиций из 9 200 на витрине и половина заказов на то, чего нет на складе, стоят дороже любого тарифа.
Если после такого расчёта разработка не нужна, мы говорим это письмом и не берём денег за консультацию. Клиент, которому продали лишнее, возвращается с претензией, а не с новым проектом.