Почему похожие интернет-магазины отличаются по стоимости в несколько раз

Запрос «нужен интернет-магазин» почти ничего не говорит о будущей разработке. В одной заявке за ним стоит каталог на 300 товаров, один склад и доставка по понятным правилам. В другой — десятки тысяч позиций, несколько поставщиков, личные цены, бонусы, синхронизация с 1С и остатки, которые обновляются чаще, чем кто-то успевает открыть Excel.

На экране разница бывает минимальной: каталог, карточка товара, корзина, оплата. Основной объём прячется в процессах, данных, интеграциях и ролях.
Кратная разница в стоимости появляется из-за количества состояний, которые нужно спроектировать, связать с системами и проверить на отказ. Склад не ответил. Цена изменилась во время оплаты. Платёж прошёл, а CRM временно недоступна. Поставщик загрузил товар, который должен пройти модерацию. Каждое такое состояние требует логики, интерфейса, проверки и поддержки.

Разберу, где оценка начинает расходиться и как мы смотрим на такие проекты в Qtim.

За одной кнопкой «купить» стоят разные роли

Сначала важно понять, кто управляет продажей.

Если ассортиментом занимается сам бизнес, логика обычно строится вокруг каталога, остатков, оплаты, доставки и админки. У команды есть понятный набор ролей: администратор, менеджер, покупатель.

У маркетплейса появляются поставщики, модераторы, комиссии, взаиморасчёты, разные права доступа и личные кабинеты. Товар добавляет один участник, проверяет другой, деньги распределяются по правилам площадки.

Для покупателя это всё ещё кнопка «купить». Для разработки — отдельный операционный слой, который двигает сроки и бюджет.

MVP начинается с границ первой версии

Мы в Qtim считаем MVP по сквозному сценарию покупки.

Покупатель должен найти товар, изучить карточку, добавить позицию в корзину, выбрать доставку и оплатить заказ. Сотрудник должен получить заявку, увидеть состав, передать дальше в обработку и обновить статус.

В «Клик ЮТ» такой сценарий связал каталог с фильтрами, разные способы оплаты и доставку с учётом местоположения клиента.

Звучит базово. Но даже в таком «базово» должны сойтись каталог, корзина, платежи, доставка и административная часть. Если сразу добавить бонусы, персональные цены, сложные акции и несколько типов клиентов, первая версия быстро перестаёт быть маленькой.

Интеграции съедают больше времени, чем кажется

До разработки нужно понять, где живут цены, остатки, заказы и клиентские данные.

Иногда всё хранится внутри сайта. Тогда проще. Чаще цены приезжают из 1С, наличие — со склада, доставку считает внешний сервис, платежи подтверждает банк, а статусы отправлений возвращает логистический партнёр.

Каждую такую связь нужно разработать, проверить и поддерживать. Что делать, если 1С прислала цену со старой скидкой? Как показать товар, если склад отдаёт остаток с задержкой в час? Куда записать заказ, если банк подтвердил оплату дважды?

На макете этого не видно. В смете — видно.

Главная сложность живёт за пределами корзины

В e-commerce самая трудная часть не всегда связана с каталогом и оплатой.

В ScanWow пользователь выбирает 3D-модель и пресет под нужный движок, а платформа готовит архив для скачивания. Внутри этого сценария — серверная обработка файлов, очередь фоновых задач, экспортёр моделей и письмо со ссылкой, когда архив готов.

Для пользователя путь короткий: выбрал, скачал, импортировал. Для разработки это отдельная продуктовая логика, которая и создаёт ценность сервиса.

Такую функцию нельзя оценивать как ещё одну кнопку в карточке товара. Она влияет на архитектуру, сроки и стоимость сильнее, чем десяток обычных экранов.

Коробка хороша, пока не мешает развитию

Готовая платформа подходит, когда процессы совпадают с её логикой: стандартный каталог, понятный заказ, типовая админка, привычные интеграции.

Проблемы начинаются при росте каталога, сложной лояльности, нестандартных правилах продажи, высоких требованиях к скорости или желании развивать продукт без постоянных обходных решений.

В 4fresh возможности 1С-Битрикс стали ограничивать развитие магазина. Мы перенесли площадку на собственное решение и сохранили профили пользователей, историю заказов и тысячи отзывов.

Миграция такого уровня — отдельная работа. Нужно перенести данные, проверить их целостность, сохранить привычный опыт для покупателей и не уронить то, что уже приносит бизнесу деньги.

Низкая оценка редко означает, что проект проще. Чаще часть состояний просто не заложили в смету: не спросили про остатки из 1С, не продумали поведение при недоступной оплате, не учли роли поставщиков. Эти сценарии никуда не деваются. Они всплывают переделкой после релиза, когда чинить уже дороже.

Первый релиз проверяет спрос

После запуска приоритеты становятся конкретнее. Уже видно, где падает конверсия, где тормозит загрузка, на каком шаге ошибаются пользователи и сколько времени сотрудники тратят на обработку заказа.

В DroneShow Gallery за 2,5 месяца мы запустили маркетплейс готовых дрон-шоу: каталог сценариев, фильтры по параметрам площадки, просмотр моделей в 3D, оплату и доступ к исходным файлам.

Первый релиз закрыл путь от просмотра модели до покупки и скачивания исходников. Редактор моделей, расширенную аналитику и дополнительные сценарии можно развивать следующим этапом, когда уже понятно, как люди пользуются продуктом.

Объём прячется за витриной

В оценке интернет-магазина мы идём от процесса продажи: кто управляет товарами, откуда приходят цены и остатки, какие системы уже есть у бизнеса, где заказ может зависнуть и что нужно для первого рабочего релиза.

В этом и есть работа интегратора: увидеть связи под витриной до того, как они расползутся по срокам.

Иногда проект можно запустить проще и дешевле, чем казалось на старте. Иногда за коротким запросом оказывается маркетплейс с интеграциями, ролями, миграцией и нетиповой логикой.

Оценка на глаз почти всегда мимо: недозаложили — сорвали сроки и бюджет, перезаложили — переплатили за то, что можно было отложить на второй этап. Дешевле разобрать состав работ до старта.

Если у вас есть идея магазина, текущая площадка или список «хотим как у конкурентов», можно разобрать это с нами. Покажем, что стоит запускать первым, какие места потянут сроки и где лучше не тащить всё в первый релиз: получить предварительный план запуска.