На первом созвоне это был «обычный магазин»: около 300 SKU, быстрый запуск, бюджет без лишнего. Через 20 минут выяснилось, что у клиента три типа цен, B2B-покупатели работают с отсрочкой, остатки приходят от поставщиков и в Excel, и по API, а доставка зависит от региона и класса товара. Формально это интернет-магазин. По сути - система продаж с разной логикой, документами и интеграциями.
Из-за таких деталей вопрос «сколько стоит сайт магазина» почти всегда бесполезен без подготовки. Самая дорогая ошибка в e-commerce - начинать с макетов, пока не описано, как бизнес в реальности продает.
Сначала надо зафиксировать модель продаж
Главный вопрос на старте - не про дизайн и не про стек. Сначала нужно понять, кто покупает и что для него считается нормальным заказом. Розница, опт, смешанная схема, дилеры, повторные закупки - это разные магазины, даже если каталог у них один.
У нас был проект для дистрибьютора расходников. Когда мы посмотрели структуру заказов, оказалось, что 70% заказов - повторные закупки от юрлиц. Витрина там была вторична: клиентам нужны персональные цены, история документов и быстрый повтор корзины. Мы собрали первую версию на Laravel 11 + PostgreSQL 16, и путь до оформления сократился с 7 шагов до 3.
Что я обычно прошу решить до оценки:
- кто покупает: B2C, B2B или смешанная модель;
- какая доля заказов повторная;
- нужны ли счета, отсрочка, договорные цены;
- что приносит деньги в первом релизе: витрина, скорость заказа или самообслуживание.
Можно определить это потом, уже в разработке, но именно в этот момент пересборка обходится дороже всего. Если роли, цены и сценарии покупки всплывают после старта, вы платите дважды: сначала за быструю версию, потом за переделку логики.
Бюджет съедают не товары, а правила и связи с внешними системами
Магазин на 5 000 товаров может оказаться проще, чем проект на 300 позиций. Если у каталога одна цена, один склад и понятная доставка, его можно собрать быстро. Когда появляются комплекты, скидки по ролям, возвраты, мультисклад и обмен с учетной системой, смета растет заметно быстрее каталога.
В одном проекте на Node.js 20 + NestJS, React и PostgreSQL 16 около 35% бюджета ушло на интеграции с 1С, CRM и службой доставки. Фронтенд на этом фоне оказался самой предсказуемой частью. Хороший вопрос на старте: откуда приходят цены, остатки и статусы, и что сломается, если они будут обновляться с задержкой хотя бы в час.
| Фактор | Сроки | Бюджет | Можно отложить в MVP |
|---|---|---|---|
| Персональные цены | растут | растет | иногда |
| Интеграция с 1С | растут сильно | растет сильно | иногда |
| Мультисклад | растут | растет | редко |
| Возвраты и обмены | растут умеренно | растет умеренно | да |
В проекте с Odoo мы решили, что обмен остатками будет простой задачей, и заложили слишком мало времени. На практике получили 3 формата данных, ручные исключения по поставщикам и потеряли 2 недели еще до нормального тестирования заказов. После этого я всегда прошу показать реальный файл обмена и живой API до подписания сметы.
Коробка кажется дешевой, пока вы не трогаете ядро
Готовая платформа подходит, когда у бизнеса типовой каталог, базовая корзина и простая доставка. Для таких задач мы иногда берем WordPress + WooCommerce или Laravel + Bagisto, если нужно быстрее выйти в релиз. Когда бизнесу нужны дилерские роли, корпоративные скидки, сложный checkout или глубокая связка с CRM, коробка начинает сопротивляться почти везде.
У клиента из оптовой торговли был такой опыт: они выбрали шаблонный движок ради экономии. Через 5 месяцев доработок смета выросла в 2,4 раза, а смешанные роли и договорные скидки все равно работали нестабильно. В итоге архитектуру пришлось пересобирать почти с нуля.
Иногда кастомная разработка дешевле коробки на дистанции 6-12 месяцев, если у бизнеса нетиповая логика продаж.
Когда коробка все-таки оправдана? Когда ограничения платформы не мешают зарабатывать: стандартный checkout, нет сложных ролей и цены не зависят от клиента.
Проектировать надо сценарии покупки, а не набор страниц
Когда говорят «нужны главная, каталог, карточка и корзина», этого недостаточно. Продают не страницы, а сценарии: первый заказ с телефона, повторный заказ, закупка от юрлица, самовывоз, возврат. Именно в этих точках проявляются реальные требования к форме заказа, оплате, документам и доставке.
На одном проекте мы включили GA4 и Яндекс Метрику еще на этапе первого релиза. Выяснилось, что мобильный пользователь сначала вводил адрес целиком, а потом узнавал, что этот способ доставки ему недоступен. Мы поменяли порядок полей: сначала способ получения, потом адрес и детали. Завершение mobile checkout выросло на 17% за 3 недели.
До
- полный адрес вводился в начале;
- часть пользователей уходила на последнем шаге;
- менеджеры добивали заказы вручную.
После
- сначала выбор доставки;
- форма показывала только нужные поля;
- +17% к завершению заказа с мобильных.
MVP нужен не для экономии, а для проверки продаж
Я предпочитаю запускать первую версию, которая уже умеет продавать и считать. Если состав этапа определен трезво, магазин можно вывести за 8-12 недель без лишней суеты и без полупустого кабинета, который потом все равно придется переделывать.
На практике для старта хватает короткого pre-discovery-документа на 2-3 страницы. В нем должны быть модель продаж, обязательные интеграции, критические сценарии, состав MVP и метрики успеха. Такой документ редко выглядит впечатляюще, но именно он обычно экономит сотни тысяч рублей уже в первом спринте.
Перед стартом лучше просить у подрядчика не «цену сайта», а список решений, без которых нельзя оценить проект: это самый дешевый способ убрать туман до первого спринта.
