Готовый шаблон, конструктор или индивидуальная разработка: что выбрать

Разбор от команды разработки AmSales.

Вопрос «шаблон, конструктор или заказная разработка» на практике почти никогда не про деньги. Он про то, насколько ваш продукт стандартный и как быстро он будет меняться. Ниже — как мы принимаем это решение на проектах и где чаще всего ошибаются.

Три варианта и что за ними стоит

Готовый шаблон

Это купленная тема (для WordPress, Tilda Store, Shopify, готовые сборки на «1С-Битрикс»). Вы получаете дизайн и типовой функционал сразу. Плюс — скорость: лендинг или простой корпоративный сайт поднимается за дни. Минус — вы живёте внутри чужих решений. Любая нестандартная логика превращается в костыль поверх шаблона, а обновления темы норовят затереть ваши правки.

Когда брать: сайт-визитка, лендинг под рекламу, блог, простой каталог без сложной механики заказа. Задача понятна, требования не будут расползаться.

Конструктор

Tilda, Webflow, Craftum, Bitrix24.Сайты. Вы собираете страницы из блоков без кода, хостинг и обновления — на стороне платформы. Хорошо ложится на маркетинговые задачи: быстро тестировать гипотезы, менять офферы, запускать промо. Оборотная сторона — вы арендуете, а не владеете. Экспорт ограничен, кастомная интеграция упирается в API платформы, а при росте нагрузки или требований вы упрётесь в потолок конструктора.

Когда брать: частая смена лендингов силами маркетолога, MVP для проверки спроса, мероприятия и акции с коротким жизненным циклом.

Индивидуальная разработка

Код пишется под вашу бизнес-логику: свой фронтенд, бэкенд, база, интеграции. Дороже и дольше на старте, но вы получаете систему, которая делает ровно то, что нужно, масштабируется и остаётся вашей. Это единственный вариант, когда продукт — не витрина, а инструмент: личный кабинет, расчётная логика, интеграция с CRM и складом, нестандартный сценарий покупки.

Когда брать: функционал — ваше конкурентное преимущество, есть сложные интеграции, высокая нагрузка, требования к безопасности или планы на долгую эволюцию продукта.

Как выбрать: четыре честных вопроса

• Насколько ваш процесс стандартный? Если он совпадает с сотней таких же — берите готовое. Если ваша механика уникальна и в ней ценность — это разработка.
• Как часто и кто будет менять контент? Маркетолог сам крутит блоки — конструктор. Меняется бизнес-логика, а не тексты — код.
• Что с интеграциями? Одна форма в CRM тянется и на конструкторе. Двусторонний обмен со складом, оплатой, 1С и телефонией на шаблоне превращается в вечную боль.
• Какой горизонт? Проверить гипотезу за месяц — конструктор. Строить продукт на годы — заказная разработка, иначе переписывать всё равно придётся, только дороже.

Типичные ошибки выбора

• Взяли шаблон под сложный продукт. Сэкономили на старте, полгода допиливали, в итоге переписали заново. Классический случай, когда «дёшево» выходит дороже всего.
• Ушли в кастом там, где хватило бы Tilda. Обратная крайность: заказали разработку под обычный лендинг, который менять раз в квартал. Деньги и время в пустоту.
• Не заложили интеграции заранее. Сайт готов, а потом выясняется, что заявки не уходят в CRM автоматически и оплата не сходится с учётом. Интеграции надо проектировать до выбора платформы, а не после запуска.
• Забыли про владение. Весь бизнес завязан на конструктор, а условия платформы или тарифы меняются — и вы заложник. Для критичных систем это неприемлемо.

Из чего складывается стоимость

Шаблон — это цена темы плюс работа по адаптации под ваш контент и бренд. Конструктор — подписка платформы плюс сборка и настройка. Разработка — оценка по трудозатратам: проектирование, дизайн, фронтенд, бэкенд, интеграции, тестирование. Важно смотреть не на цену запуска, а на стоимость владения на горизонте двух-трёх лет: дешёвый старт на неподходящем решении почти всегда даёт дорогую переделку.

Короткий вывод

Стандартная задача с понятными границами — шаблон. Быстрые маркетинговые гипотезы и правки силами команды — конструктор. Уникальная логика, серьёзные интеграции и долгий горизонт — заказная разработка. Здоровый подход — гибридный: не решать идеологически, а собирать из готового всё, что можно, и писать кодом только то, что действительно приносит ценность. Начинать стоит не с выбора инструмента, а с описания задачи и требований — тогда инструмент выбирается почти сам.