«Почему разработка маркетплейса вышла дороже сметы?» — этот вопрос задаёт себе каждый второй заказчик, который впервые строит торговую платформу. Причина почти никогда не в жадности подрядчика. Перерасход закладывается ещё на этапе переговоров — в размытых требованиях, неверных допущениях и отсутствии буфера на интеграции. Ниже — шесть конкретных механизмов, которые раздувают бюджет, и практические способы их нейтрализовать.
Размытое техническое задание: платишь за угадывание
Самая частая причина перерасхода — ТЗ, написанное в духе «хотим маркетплейс как Wildberries, только свой». Команда оценивает минимально понятный объём, а в процессе выясняется, что заказчик имел в виду совсем другое. Каждое уточнение требований на стадии разработки обходится в 5–10 раз дороже, чем на стадии проектирования.
Как избежать: перед подписанием договора зафиксируйте функциональные требования постранично: роли пользователей, сценарии оплаты, логику комиссий, механику возвратов. Хорошее ТЗ для маркетплейса занимает 40–80 страниц — это не бюрократия, а страховка бюджета.
Недооценённые интеграции со сторонними сервисами
Маркетплейс — это не монолит. Он живёт за счёт интеграций: платёжные шлюзы, службы доставки, системы аналитики, CRM, 1С, SMS-провайдеры. Каждая интеграция в смете выглядит как строчка «подключение API — 20 часов». На деле:
- документация у провайдера устарела или неполная;
- тестовая среда ведёт себя иначе, чем боевая;
- платёжный шлюз требует дополнительную сертификацию PCI DSS;
- служба доставки меняет формат webhook прямо в ходе проекта.
Реальный разброс по времени интеграции — от ×1,5 до ×3 от первоначальной оценки. Закладывайте буфер 30% на каждую внешнюю зависимость и требуйте от подрядчика список рисков по каждому API ещё до старта.
Почему разработка маркетплейса вышла дороже сметы из-за смены требований
Change request — главный враг фиксированного бюджета. Бизнес меняется: появляется новый конкурент, меняется модель монетизации, маркетинг просит добавить реферальную программу. Каждое изменение после старта разработки тянет за собой:
- Переработку архитектуры или базы данных.
- Регрессионное тестирование уже готовых модулей.
- Задержку релиза, которая стоит денег сама по себе.
Решение: внедрите процедуру контроля изменений (change management). Любой новый запрос оформляется письменно, оценивается командой и утверждается спонсором проекта. Это не бюрократия — это способ сделать цену изменения видимой до его принятия.
Скрытые расходы на инфраструктуру и DevOps
В смете написано «хостинг». Заказчик думает: «ну, сервер, тысяч пять в месяц». По факту инфраструктура маркетплейса — это:
| Компонент | Типичная ошибка в смете | Реальная статья расходов |
|---|---|---|
| Серверы | Один VPS | Кластер с автомасштабированием под пиковые нагрузки |
| CDN | Не учтён | Обязателен при каталоге от 10 000 SKU |
| CI/CD | «Настроим сами» | 40–80 часов DevOps-инженера |
| Мониторинг | Не учтён | Платные инструменты + дежурство |
| Резервное копирование | Базовый бэкап | Geo-redundant storage для данных транзакций |
Перед подписанием контракта попросите подрядчика отдельно расписать инфраструктурную архитектуру и её стоимость на 12 месяцев вперёд.
Недооценка нагрузочного тестирования и безопасности
Маркетплейс обрабатывает деньги и персональные данные. Это означает обязательный аудит безопасности, тестирование на проникновение и соответствие 152-ФЗ. Многие команды закладывают в смету «QA» — и подразумевают функциональное тестирование. Нагрузочные тесты, pentest и работа с уязвимостями — отдельные статьи, каждая от 100 000 ₽ и выше. Если их нет в смете, они появятся после первой утечки данных или падения под нагрузкой — только уже в виде штрафов и репутационных потерь.
Узнать заранее, что входит в стоимость разработки маркетплейса у конкретного подрядчика, — значит избежать неприятных сюрпризов в середине проекта.
Постзапусковые доработки: «мы думали, это входит в поддержку»
Маркетплейс не заканчивается в день релиза. После запуска начинается самое интересное: реальные пользователи находят сценарии, которые никто не предусмотрел, мобильные устройства ведут себя иначе, чем тестовые, первые продавцы просят функции, которых нет. Если в договоре не прописан чёткий гарантийный период и объём постзапусковой поддержки, каждый такой запрос выставляется как новый проект.
Что фиксировать в договоре:
- гарантийный период — минимум 3 месяца на исправление дефектов без доплаты;
- SLA на реакцию и устранение критических багов;
- объём часов технической поддержки в месяц и их стоимость;
- порядок приёмки каждого этапа с чёткими критериями.
Часто задаваемые вопросы
Можно ли зафиксировать бюджет на маркетплейс полностью?
Полная фиксация реальна только при детальном ТЗ и неизменных требованиях — то есть практически никогда. Рабочий подход: фиксировать стоимость каждого этапа отдельно, закладывать contingency-буфер 15–20% от общей суммы и прописывать процедуру оценки изменений. Это даёт предсказуемость без иллюзии абсолютной фиксации.
Как выбрать подрядчика, который не выйдет за смету?
Запросите у подрядчика примеры смет по завершённым проектам и сравните плановые цифры с фактическими. Спросите, какой процент проектов завершается в бюджете. Хороший показатель — отклонение не более 15–20%. Также важно, чтобы команда сама инициировала обсуждение рисков, а не ждала вопросов от заказчика.
Что делать, если бюджет уже вышел за рамки?
Первый шаг — аудит текущего состояния: что уже сделано, что в работе, какова реальная оценка оставшегося объёма. Второй — приоритизация: определите MVP-функционал, без которого запуск невозможен, и заморозьте всё остальное. Третий — пересмотрите договор и зафиксируйте новый scope письменно, чтобы не повторить ситуацию на следующем этапе.
Итог: бюджет контролируют до старта, а не после
Перерасход на маркетплейсе — почти всегда системная проблема, а не разовая случайность. Размытое ТЗ, недооценённые интеграции, отсутствие процедуры изменений, пропущенные статьи по инфраструктуре и безопасности — каждый из этих факторов в одиночку способен добавить к смете 20–40%. Вместе они легко удваивают бюджет.
Решение одно: тратить время и деньги на проектирование до старта разработки, а не экономить на нём. Детальное ТЗ, архитектурный аудит и прозрачная стоимость разработки маркетплейса с разбивкой по этапам — это не лишние расходы, а страховка от куда больших потерь.
Если вы планируете запуск маркетплейса и хотите получить честную оценку бюджета без скрытых статей — обсудите проект с командой Aris.Web. Звоните: +7 (977) 326-69-09 или оставьте заявку на странице arisweb.ru/kontakty. Разберём ваш сценарий, укажем на риски и предложим структуру бюджета, которая не изменится в середине пути.