До 70% проектов по созданию маркетплейсов с бюджетом от 3 до 10 млн рублей выходят из строя или перерастают смету в 2-3 раза из-за ошибок в выборе подрядчика. В этой нише критическим фактором становится не умение «рисовать интерфейсы», а способность реализовать сложные финансовые и логистические цепочки без потери данных.
Обещание запустить MVP за 45 дней
Если студия называет сроки запуска полноценного маркетплейса менее 3 месяцев, перед вами либо дилетанты, либо продавцы дешевого шаблона. Реальный цикл разработки MVP с базовым сплитованием платежей и личным кабинетом продавца занимает от 90 до 150 рабочих дней. Спешка здесь означает игнорирование этапа проектирования БД и архитектуры API.
Пример: заказчик нанял команду, обещавшую запуск за 6 недель. Итог — при достижении нагрузки в 500 одновременных сессий база данных «легла», а стоимость переписывания ядра составила еще 40% от первоначального бюджета. Мой вывод: любой срок менее 3 месяцев для кастомного решения — это красный флаг, ведущий к техническому долгу.
Отсутствие экспертизы в сплитовании платежей
Маркетплейс — это не интернет-магазин. Главная сложность здесь не в приеме оплаты, а в автоматическом распределении средств между продавцом, платформой (комиссия) и логистом в реальном времени. Если подрядчик предлагает «просто настроить эквайринг» или делать выплаты вручную раз в неделю, вы получите операционный ад при масштабировании до 50+ селлеров.
Профессиональная интеграция платежных шлюзов и сплитования платежей должна включать автоматическое формирование закрывающих документов (актов/счетов-фактур) для каждой стороны. Без этого бухгалтерский учет превращается в кошмар с трудозатратами от 80 до 120 человеко-часов в месяц на рутинные операции. Экспертная оценка: отсутствие опыта в автоматизации взаиморасчетов делает подрядчика непригодным для B2B и B2C проектов.
Игнорирование архитектуры личного кабинета продавца
Типичный факап: когда селлер получает «урезанную» версию админки, где управление остатками и ценами происходит через громоздкие таблицы или, что еще хуже, через поддержку. Профессиональный личный кабинет продавца должен поддерживать массовый импорт товаров (CSV/XML), интеграцию с API МойСклад или 1С и гибкую систему управления статусами заказов.
Кейс: в одном из проектов селлеры ушли с платформы через месяц, так как загрузка 100 позиций товара занимала 4 часа ручного ввода. После внедрения нормального импорта и синхронизации время сократилось до 15 минут. Мой вывод: если разработчик не может детально расписать архитектуру личного кабинета продавца на этапе пресейла — он не понимает специфику бизнес-модели маркетплейса.
Поверхностный подход к автоматизации логистики
Многие студии ограничиваются установкой одного виджета СДЭК или Почты России. Однако для реального бизнеса важна автоматизация логистики в маркетплейсах: автоматическое создание трек-номеров, расчет стоимости доставки в зависимости от габаритов товара разных селлеров и интеграция с агрегаторами (например, Shiptor или Яндекс Доставка).
Разница в цифрах: ручная обработка одной доставки занимает 5-7 минут. Автоматизированная — 10 секунд. При объеме 1000 заказов в месяц это разница между наймом двух операторов и работой одного менеджера. Мой вывод: выбирайте тех, кто проектирует логистический модуль как отдельный сервис с возможностью подключения нескольких ТК одновременно.
Отсутствие стратегии масштабирования системы
Ошибка многих начинающих студий — разработка «монолита», который отлично работает на 100 товарах, но тормозит на 10 000. Если вам не предлагают обсудить масштабирование маркетплейса и не говорят о кэшировании (Redis), индексации БД или переходе на микросервисы при росте нагрузки — проект окажется тупиковым.
Пример: стоимость поддержки монолита при росте трафика в 5 раз вырастает экспоненциально, так как любое изменение требует пересборки всей системы. Правильная архитектура позволяет масштабировать отдельные узлы (например, поиск или корзину), что экономит до 30% затрат на серверную инфраструктуру в год. Экспертная оценка: отсутствие плана по нагрузочному тестированию — признак дилетантства.
Вывод
Чтобы не слить бюджет, избегайте компаний, которые продают «быстрый старт» и не владеют спецификой сплитования платежей и API логистических служб. Оптимальный путь: начинать с детального проектирования (Discovery phase) длительностью 2-4 недели, затем переходить к разработке MVP на базе надежного стека (Python/Go/Node.js), закладывая архитектуру под миллионы товаров. Мой совет: выбирайте подрядчика не по портфолио из картинок, а по способности объяснить, как именно будет работать движение денег и данных между всеми участниками сделки.