Два интернет-магазина могут выглядеть почти одинаково на скриншоте и отличаться по стоимости в разы. Причина обычно находится не в цвете кнопок, а в невидимой части проекта.
Когда я оцениваю разработку, мне важнее понять, как товар попадает на сайт, как обновляются остатки, что происходит после заказа и какие системы должны обменяться данными.
Витрина — только верхний слой
Каталог, фильтры, карточка, корзина и оформление видит покупатель. Под ними могут быть импорт ассортимента, управление ценами, интеграция с учётом, CRM, платежами, доставкой, уведомлениями и аналитикой.
Если всё это типовое, проект проще. Если данные грязные, процессы нестандартные или у бизнеса несколько систем, значительная часть работы уходит на согласование и интеграцию.
Стоимость создают требования к эксплуатации
Кто обновляет каталог? Как быстро меняются цены? Что будет при сбое оплаты? Как отслеживается заказ? Кто видит ошибку интеграции? Как сайт индексируется и измеряется?
Чем выше требования к надёжности и управляемости, тем больше работы остаётся за пределами красивого макета.
Как сравнивать предложения подрядчиков
Я бы просил одинаково описать границы: что входит в импорт, интеграции, аналитику, SEO-базу, тестирование, перенос на production и поддержку после запуска. Тогда цена становится сопоставимой.
Ограничение простое: точную стоимость нельзя честно назвать по одному слову «интернет-магазин». Сначала нужен хотя бы минимальный контур процессов и данных.
Цена должна быть привязана к границам ответственности
Одно предложение может включать только разработку витрины, другое — перенос каталога, подключение аналитики, production-развёртывание, интеграции и контроль после запуска. Без одинакового перечня работ две цифры нельзя честно сравнить.
Поэтому до оценки полезно зафиксировать не только функции, но и результат каждого этапа: что будет реально доступно владельцу и покупателю, какие данные уже загружены, какие внешние системы связаны и кто принимает работу. Тогда стоимость становится следствием объёма, а не загадкой подрядчика.
Каталог может быть самым дорогим местом проекта
Если товаров немного и данные уже аккуратные, каталог действительно выглядит простой задачей. При большом ассортименте появляется импорт, нормализация названий, категории, характеристики, изображения, варианты, цены и остатки. Если исходные данные приходят из нескольких файлов или учётной системы без единой структуры, значительная часть проекта превращается в работу с данными.
Эта работа почти не видна на макете. Две витрины могут выглядеть одинаково, но в одном случае товары внесены вручную один раз, а в другом существует постоянная синхронизация с источником, контроль ошибок и правила обновления. Это разные системы и разная стоимость эксплуатации.
Интеграция — не просто «подключить API»
Сам факт наличия API не отвечает на вопрос, как системы должны обмениваться состоянием. Нужно определить, какая система главная для цены, остатка, клиента и заказа; какие события передаются; что делать при недоступности сервиса; можно ли безопасно повторить запрос и как обнаружить расхождение.
Если эти правила не описаны, интеграция может технически отвечать без ошибок и всё равно создавать неправильный результат. Поэтому в оценку входит не только обмен запросами, но и бизнес-логика вокруг них, журналирование и обработка исключений.
Оплата и доставка тоже бывают разной глубины
Стандартный сценарий может ограничиваться одним провайдером оплаты и несколькими способами доставки. В другом магазине нужны расчёт по регионам, несколько служб, самовывоз, ограничения по товару, разные способы оплаты или связь со статусом заказа. На экране покупатель по-прежнему видит несколько полей, но за ними может работать существенно разная логика.
Особенно важно заранее договориться, что происходит при неуспешной оплате, повторном callback или отмене. Если исключения оставлены «на потом», стоимость просто переезжает из разработки в ручную работу менеджеров.
Качество запуска тоже имеет стоимость
Тестирование, перенос на production, резервное копирование, базовая безопасность, производительность и контроль после релиза редко становятся главным пунктом презентации. Но без них магазин может выглядеть готовым на тестовом адресе и оставаться хрупким в реальной эксплуатации.
Я бы отдельно спрашивал, что проверяется перед запуском: мобильный путь заказа, уведомления, неуспешные сценарии оплаты, аналитические события, индексируемость и восстановление из резервной копии. И кто отвечает за проблему после запуска, если она обнаружена уже на реальном трафике.
Дизайн влияет на цену, но не объясняет её один
Уникальный интерфейс, сложная анимация и большая работа с UX действительно увеличивают объём. Но простой визуально магазин может быть дорогим из-за данных и интеграций. И наоборот, выразительная витрина на типовой инфраструктуре иногда оказывается предсказуемее сложного «невидимого» проекта.
Поэтому количество экранов не является хорошей единицей сравнения. Бизнес покупает не набор макетов, а способность системы поддерживать конкретный путь продажи и дальнейшие изменения.
Нужно различать стоимость запуска и стоимость владения
После релиза остаются хостинг или тариф платформы, обновления, поддержка интеграций, изменение каталога, мониторинг и доработки. Дешёвая разработка может требовать дорогого постоянного участия. Более дорогой старт иногда уменьшает ручную работу и будущие изменения. Без горизонта эксплуатации сравнение получается односторонним.
Я бы не пытался заранее посчитать годы вперёд до копейки. Достаточно увидеть основные постоянные статьи и понять, какие процессы требуют человека каждый день. Это уже помогает отличить разовую цену проекта от реальной цены канала.
Как получить сравнимые предложения
Для сравнения подрядчиков я бы зафиксировал один и тот же объём: источник и размер каталога, способы оплаты и доставки, интеграции, роли пользователей, аналитику, SEO-базу, требования к импорту, перенос на production и поддержку. Затем попросил явно отметить, что входит, что не входит и какие допущения сделаны.
Ещё лучше привязать каждый этап к проверяемому результату. Не «интеграция с CRM», а, например, подтверждённый заказ создаёт объект с нужными данными и его можно прочитать обратно. Не «настроена аналитика», а тестовый заказ появляется в согласованном отчёте с источником.
Цена становится понятнее после определения границ ответственности
Один подрядчик может оценивать только разработку витрины, другой — перенос данных, запуск, интеграции и период стабилизации. Обе цены сами по себе могут быть честными, но описывать разные результаты. Пока границы не совпали, вопрос «кто дешевле» не имеет смысла.
Поэтому точная оценка начинается не с количества страниц, а с маршрута товара, заказа и данных. Именно невидимая часть чаще всего объясняет, почему внешне похожие интернет-магазины стоят по-разному.
Так оценка остаётся связанной с реальным объёмом работ, а не с внешним сходством страниц.
Мы начинаем оценку с состава магазина и интеграций, чтобы цена была привязана к реальной системе, а не к количеству экранов: разработка собственного интернет-магазина