Кастомный eCommerce против платформ: что масштабируется лучше?

Shopify — хороший продукт. WooCommerce — разумный выбор. BigCommerce, Magento, Wix — все они существуют, потому что решают реальную проблему реального сегмента рынка. Если вы запускаете новый магазин, выбор одной из этих платформ — скорее всего, правильное решение.

Ошибка не в том, что вы их используете. Ошибка в том, что вы остаётесь на них слишком долго.

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

Разумная отправная точка

Готовые платформы дают вам обработку платежей, управление товарами, хостинг, поток оформления заказа и экосистему плагинов — из коробки, в первый день. Для бизнеса, который ещё не подтвердил product-market fit, это правильный компромисс: принять ограничения в кастомизации в обмен на скорость выхода на рынок и низкие операционные накладные расходы.

При GMV ниже $1M у большинства бизнесов нет проблем, которые платформа не может решить. Есть проблемы крупнее — привлечение клиентов, выбор товаров, операции. Тратить инженерный бюджет на кастомную корзину на этом этапе — это отвлечение.

Платформа делает свою работу. Дайте ей её делать.

Точка перегиба

Точка перегиба — не конкретная цифра выручки. Это когда разрыв между тем, что вам нужно от платформы, и тем, что она реально делает, начинает поглощать реальные ресурсы.

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

5 сигналов, что вы переросли платформу

1. Конфликты плагинов блокируют деплои. Нужно три плагина, чтобы покрыть фичу, которая должна быть нативной. Два из них обновляются независимо и ломают друг друга. Разработчик тратит больше времени на управление зависимостями, чем на доставку фич. Это нарастающая проблема — она усугубляется с каждой новой нужной функциональностью.

2. Корзину нельзя кастомизировать достаточно. Конверсия корзины — самая критичная метрика в eCommerce. Платформы вроде Shopify Plus дают некоторую кастомизацию за значительную доплату, но вы всё равно работаете в рамках ограничений, которые не выбирали. Если роадмап оптимизации конверсии упирается в то, что позволяет платформа — это прямое ограничение выручки.

3. Отчётность требует сторонних обходных решений. Вы экспортируете CSV в дата-вейрхауз, потому что отчётность платформы не даёт нужного. Купили BI-инструмент в качестве компенсации. Аналитики пишут SQL против внешней базы данных, которая в одну версию API может сломаться. Инфраструктура данных, которая вам реально нужна, находится за пределами платформы, за которую вы платите для ведения бизнеса.

4. Производительность ограничена платформой. Core Web Vitals важны и для SEO, и для конверсии. На хостинговых платформах вы не контролируете серверный стек, конфигурацию CDN или пайплайн рендеринга. Можно оптимизировать изображения и минифицировать скрипты, но вы работаете в рамках потолка, который не устанавливали. Для высоконагруженных магазинов этот потолок реален и измерим.

5. Привязанность к вендору стоит реальных денег. Комиссии сверх комиссий платёжного процессора. Принудительные подписки на приложения для доступа к API. Платформенные сборы, которые растут с выручкой независимо от инфраструктурных затрат. При определённом GMV структура затрат платформы перестаёт иметь смысл. Вы платите за R&D и продажи платформы, а не за инфраструктуру, которую реально используете.

Что кастомная разработка на самом деле означает

Кастомный eCommerce не означает создание платёжного шлюза с нуля. Это было бы безумием. Это означает composable commerce: сборку лучших в классе компонентов — Stripe или Adyen для платежей, Algolia для поиска, headless CMS для контента, специализированную OMS для выполнения заказов — и построение логического слоя самостоятельно.

Корзина — ваша. Модель данных — ваша. Архитектура интеграций — ваша. Вы не боретесь с допущениями платформы; вы реализуете собственные.

Headless commerce — где фронтенд (React, Next.js) полностью отделён от бэкенд-логики — наиболее распространённый паттерн на этом уровне. Фронтенд-команда движется без ожидания бэкенд-ограничений, и компоненты можно менять независимо, не перестраивая всё.

Сравнение полной стоимости

	Платформа + плагины	Кастом
Начальные затраты на создание	Низкие	Высокие
Постоянные платформенные сборы	$500–$5 000+/месяц	Только хостинг
Накладные расходы на разработку	Обходные решения, обновления	Работа над фичами
Потолок кастомизации	Определяется платформой	Отсутствует
Владение данными	Данные у платформы	Всё ваше
Стоимость масштабирования	Сборы растут с GMV	Инфраструктура масштабируется с нагрузкой

При $5M GMV математика часто начинает переворачиваться. При $10M GMV стоимость оставания на платформе нередко превышает амортизированную стоимость кастомной сборки в течение 18–24 месяцев. Этот расчёт стоит сделать явно.

Путь миграции

Главная причина беспокойства при переходе на кастом — сама миграция. Ответ — не одномоментный переход, а поэтапная смена.

Начните с частей, где вы наиболее ограничены: как правило, корзина и отчётность. Постройте их кастомными, направьте туда трафик, держите платформу для всего остального. Когда кастомные системы доказали свою состоятельность — мигрируйте каталог, потом инвентарь, потом аккаунты клиентов. Работайте параллельно столько, сколько нужно.

Полного отключения нет. Платформа постепенно выводится из эксплуатации за 3–6 месяцев.

Технические предпосылки: правильный API-слой на вашем кастомном бэкенде, план миграции данных, учитывающий историю заказов, аккаунты клиентов и SEO-URL, и путь отката для каждой фазы.

Кому не стоит переходить на кастом

Не каждому бизнесу при масштабировании нужна кастомная платформа. Честно ответьте, относится ли это к вам:

• GMV ниже $1M: экономика не работает. На этом этапе платформенные расходы ничтожны по сравнению с затратами на разработку.
• Нет выделенной инженерной команды: кастомный eCommerce требует постоянных инженерных инвестиций. Единовременная сборка без бюджета на поддержку хуже платформы.
• Каталог менее 500 SKU без сложных вариантов: платформы справляются с этим хорошо. Кастом ничего не даёт.
• Нет чёткого ограничения платформы, вызывающего измеримую боль: не стройте кастом, потому что думаете, что он может понадобиться. Стройте, когда можете указать на конкретное влияние на выручку или скорость разработки, вызванное платформой.

Бизнес-кейс для кастома должен основываться на конкретных, измеримых затратах. Если вы не можете сформулировать, во что вам обходится платформа в конкретных терминах — скорее всего, время ещё не пришло.

Столкнулись с описанными сигналами и пытаетесь понять, оправдана ли кастомная сборка? Напишите нам на hello@cimpleo.com. Разберём цифры и скажем, что бы мы реально рекомендовали.