Как выбрать платформу для интернет-магазина: критерии сравнения

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

14 сентября 2026 Бизнес 17 мин чтения

---

Платформа для интернет-магазина: из чего складывается выбор

Короткий ответ: универсальной платформы нет. Проверить спрос быстрее всего на арендованном конструкторе. Типовой каталог при своей команде разработки удобно вести на CMS с открытым кодом или на коробочной лицензии. Растущему магазину с нестандартными сценариями продаж, мобильным приложением и обменом с 1С и маркетплейсами обычно подходит модульная платформа или заказная разработка.

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

Платформой здесь называем не только систему управления содержимым. У интернет-магазина она закрывает корзину и оформление заказа, оплату, личный кабинет, программу лояльности, обмен с учётной системой и службами доставки, а часто — ещё и мобильное приложение. Как устроена сама система управления сайтом, разобрано в материале «Что такое CMS»; здесь речь о платформе как о канале продаж целиком.

Вопрос выбора обычно возникает в одной из трёх ситуаций:

• Первый запуск. Продажи шли через маркетплейсы или соцсети, теперь нужен свой магазин. Сравнение сценариев — в разборе о маркетплейсе с нуля или на платформе.
• Текущее решение перестало справляться. Доработки идут месяцами, сайт тормозит в распродажи, данные расходятся с учётом.
• Нужен второй канал. К сайту добавляется мобильное приложение для e-commerce, и встаёт вопрос: делать его отдельно или на общей основе с сайтом.

Пять типов платформ: сильные стороны и ограничения

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

Отдельно встречается headless-подход («без головы»): хранение товаров и витрина разделены и обмениваются данными через API — программный интерфейс. Это не шестой тип, а архитектура, которая доступна и в открытом коде, и в модульной платформе, и в заказной разработке. Смысл в ней появляется, когда одни и те же данные нужны сразу на сайте, в приложении и на экранах в торговом зале.

Модульная платформа — модель, в которой работает команда FITTIN. Магазин собирают из готовых модулей — каталог, поиск и фильтры, корзина и оформление заказа, оплата, личный кабинет, лояльность, push-уведомления, — настраивают под бренд и дописывают код для уникальных сценариев. Подробнее о подходе — в разборе модульной платформы для e-commerce, сравнение с заказной разработкой и готовыми решениями — в материале о трёх моделях разработки. Крайний случай — разработка ПО на заказ, когда модулей не хватает совсем.

Десять критериев сравнения платформ

Критерии ниже работают для любого типа платформы. У каждого есть вопрос, который стоит задать продавцу, и проверка, которую можно сделать самостоятельно, — вторая надёжнее первой.

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

1. Модель владения и доступ к исходному коду

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

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

2. Каталог и структура данных

500 товаров с тремя свойствами и 30 000 товаров с размерными сетками, цветами и комплектами — разные задачи для платформы. Спросите, как устроены варианты товара, сколько свойств можно фильтровать одновременно, как хранятся остатки по складам и магазинам. У одежды своя специфика — сетки EU/RU и ракурсы фото, о ней в материале про приложение для магазина одежды и обуви. У товаров для ремонта — расчёт по площади, распил и колеровка, пример — приложение для магазина товаров для дома и ремонта.

3. Интеграции с учётом, оплатой, доставкой и маркетплейсами

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

• Учётная система — 1С: товары, цены, остатки, заказы. Как устроен обмен — в материале про интеграцию интернет-магазина с учётной системой и в разборе автоматизации учёта товара в рознице.
• Маркетплейсы — Wildberries, Ozon, Яндекс Маркет: единые остатки и цены.
• CRM и программа лояльности — профиль покупателя, бонусы, рассылки; подробнее — интеграция с CRM.
• Доставка — СДЭК, Boxberry, Почта России, свой курьер.
• Эквайринг и платёжные шлюзы — банковские карты, СБП, оплата бонусами.

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

4. Каналы продаж: сайт, приложение и магазины приложений

Если через год вместе с сайтом появится приложение, этот критерий стоит оценить уже сейчас. Когда витрину и приложение делают на разных технологиях, у бизнеса две команды, две очереди задач и два бюджета на одну функцию. Одна кодовая база на Flutter — открытой технологии Google — даёт из общего кода и сайт интернет-магазина, и приложения для App Store, Google Play, RuStore и AppGallery.

У магазинов приложений свои правила проверки — например, требования Apple к публикации и правила распространения в Google Play. Платформа должна брать эту работу на себя, а не оставлять её владельцу магазина. Какие площадки нужны российскому магазину — в разборе сторов 2026 года. Насколько весомым бывает мобильный канал, видно по кейсу Gulliver Family: на приложение приходится 50% дохода ритейлера, а через него идёт 80% мобильного трафика. Как сайт и приложение живут на общей кодовой базе, показано в разборе кейса Fashouse.

Производительность и пиковая нагрузка

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

Что стоит измерить или запросить у поставщика:

• Скорость каталога с фильтрами — именно с фильтрами и сортировкой, а не главной страницы.
• Время оформления заказа под нагрузкой — корзина и оплата важнее витрины.
• Результаты нагрузочного тестирования — сколько одновременных покупателей выдерживает оформление заказа и что происходит при превышении. Как проводят такие проверки — на странице нагрузочного тестирования.
• Кто масштабирует серверы — провайдер, подрядчик или ваша команда.

Здесь у конструктора сильная позиция: нагрузку держит провайдер, и владельцу магазина об этом думать не нужно — пока магазин укладывается в тариф. На открытом коде за масштабирование отвечает владелец. Подробнее — в материале о высоконагруженных системах в e-commerce, а о скорости мобильного приложения — в разборе производительности Flutter-приложения.

Дизайн витрины и удобство покупки

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

Три вопроса, которые проясняют границу:

1. Можно ли изменить порядок шагов оформления заказа и убрать лишние поля?
2. Можно ли сделать карточку товара под свой ассортимент — ракурсы, видео, подбор размера, комплекты?
3. Совпадает ли интерфейс сайта и приложения, или это два разных продукта с разной логикой?

На модульной платформе и в заказной разработке интерфейс собирают под бренд — это отдельная работа, описанная на странице UX/UI-дизайна приложения и сайта. Если магазин уже работает и вопрос в том, мешает ли интерфейс покупкам, начинают с аудита UX/UI, а гипотезы проверяют A/B-тестированием. Какие решения в интерфейсе влияют на заказы — в материале о дизайне интерфейсов для конверсии.

Скорость запуска и доработок

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

По сроку запуска конструктор впереди в разы — для проверки спроса это решающий довод. По скорости доработок впереди решения с доступом к коду. Модульная платформа укладывает интеграцию под бренд в срок до 30 рабочих дней по трём причинам. Первая: исследование, техническое задание и дизайн идут одновременно на разных ролях команды. Вторая: тестировщики подключаются с первой итерации, а не после завершения разработки. Третья: каталог, корзина, оплата и лояльность уже написаны и проверены на прошлых проектах — их не пишут заново, а настраивают.

Продвижение в поиске, безопасность и поддержка

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

8. Инструменты продвижения

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

9. Безопасность, обновления и поддержка

Здесь три вопроса: кто ставит обновления безопасности, за какое время реагируют на сбой и где хранятся персональные данные покупателей. На конструкторе обновления входят в подписку. На открытом коде они целиком на владельце: заброшенное расширение остаётся уязвимостью. Схему хранения персональных данных согласуйте с юристом, но технически платформа должна позволять выполнить требования законодательства. Для компаний с госучастием важен и статус ПО: платформа FITTIN внесена в реестр российского программного обеспечения под номером 2487103.

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

Стоимость владения платформой за три года

Десятый критерий чаще всего считают неправильно — по цене запуска. Цена запуска видна сразу, а стоимость владения набирается годами: подписки на расширения, часы поддержки, доработки, второй канал продаж. Сравнивать нужно корзину расходов целиком.

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

Как устроена оплата модульной платформы

Модель FITTIN состоит из трёх частей, и называть их по отдельности нельзя — одна цифра без двух других вводит в заблуждение. Первое — единоразовая интеграция под бренд: настройка модулей, фирменный дизайн, подключение учётной системы, оплаты и доставки, публикация; срок — до 30 рабочих дней. Второе — ежемесячные лицензионные платежи, в которые уже включены все затраты на техническую поддержку команды FITTIN: мониторинг, обновления модулей и обновления безопасности. Собственная команда разработки для базового сопровождения не требуется.

Третье — новый функционал и доработки оплачиваются отдельно, по модели Time & Materials: перед стартом задачи — оценка в часах, оценки и фактические часы видны в трекере задач. Пакеты различаются тем, кто делает интеграции: в ПРО 1С, CRM и склад подключает ваша команда или подрядчик, в ПРО+ всё делает FITTIN, Индивидуальный — под нестандартные условия. Актуальные суммы с НДС — на странице тарифов.

Что забывают заложить в расчёт

• Перенос данных. Чем меньше порядка в текущей базе, тем дороже переезд: товары, свойства, бонусные баллы, история заказов.
• Платные расширения. Функции, которых нет в базовом тарифе конструктора или движка, оплачиваются отдельно и ежемесячно.
• Второй канал продаж. Приложение, заказанное отдельно от сайта, — второй бюджет на каждую функцию.
• Рост нагрузки. Переход на старший тариф или новые серверы при росте продаж.
• Выход с платформы. Стоимость переезда, если через три года платформа перестанет подходить.

Типовые ошибки при планировании бюджета собраны в материале о семи ошибках бюджета разработки.

Матрица с весами: как сравнить платформы на своих данных

Десять критериев весят по-разному в зависимости от задачи. Магазину, который проверяет спрос, важнее скорость запуска и цена входа. Сети с офлайн-точками и приложением — интеграции, каналы продаж и владение кодом. Поэтому сравнение удобно вести матрицей: у каждого критерия свой вес, у каждой платформы — оценка по нему.

Веса — пример по нашему опыту, а не норматив: поменяйте их под свою ситуацию до того, как увидите оценки платформ, иначе веса начнут подгонять под понравившийся вариант.

Как проставить оценки

Каждой платформе из короткого списка ставят оценку от 1 до 5 по каждому критерию — на основании проверок из таблицы критериев, а не презентации. Оценку умножают на вес, произведения складывают и делят на 100: получается итог по той же пятибалльной шкале. Одно правило важнее итоговой суммы: оценка 1 по критерию с весом от 15% — это стоп-фактор, даже если в сумме платформа впереди.

Пример расчёта

Условный пример: две платформы разных типов, оценки проставлены для иллюстрации метода — на ваших данных они будут другими.

С одними и теми же оценками победитель меняется вместе с профилем. Для проверки спроса впереди конструктор: скорость запуска и цена входа весят 45%. Для растущего магазина и сети перевес у модульной платформы: интеграции, каналы и владение кодом весят 35% и 45% соответственно. Матрица не выбирает за вас — она показывает, какие критерии решили исход, и делает спор о платформе разговором о приоритетах бизнеса.

Как проверить платформу до договора: пять шагов

Матрица работает, только если оценки основаны на проверках. Пять шагов ниже превращают выбор из сравнения презентаций в сравнение фактов.

Шаг 1. Опишите сценарии, а не функции

«Нужна корзина» есть у всех платформ. «Покупатель оформляет заказ на юридическое лицо с отсрочкой платежа и забирает его в магазине» — есть не у всех. Соберите 10–15 сценариев, которые приносят деньги или создают нагрузку на поддержку, и отметьте обязательные. Если требования отделов расходятся, помогает бизнес-аналитика проекта или Discovery-фаза — предпроектное исследование.

Шаг 2. Соберите короткий список из 3–4 платформ разных типов

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

Шаг 3. Демонстрация на ваших данных

Попросите загрузить на демонстрационный стенд 200–300 ваших товаров со свойствами и пройти обязательные сценарии из шага 1. Демонстрация на чужом аккуратном каталоге показывает возможности платформы, а не то, как она поведёт себя с вашими данными.

Шаг 4. Проверьте выход до входа

Запросите тестовую выгрузку каталога, заказов и клиентов, уточните, какие доступы получите на руки: серверы, репозиторий, аналитика, аккаунты в магазинах приложений. Кому принадлежат код, данные и аккаунты, должно быть записано в договоре, а не обещано на встрече.

Шаг 5. Посчитайте владение и зафиксируйте условия поддержки

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

Кейсы: как выбор платформы отражается на результате

Четыре проекта, где один из критериев оказался решающим. Цифры — со страниц кейсов.

Как российский онлайн-ритейл распределяется по каналам и сезонам, разбирает Data Insight, мировую статистику e-commerce собирает Statista — обе полезны, когда выбор платформы нужно обосновать цифрами рынка. Остальные проекты — в разделе кейсов.

Итог: какую платформу выбрать под задачу

Сводка, по которой можно соотнести ситуацию с типом платформы.

Три вывода. Первый: платформу выбирают по модели владения — что можно поменять без чужого разрешения и что забрать при уходе. Второй: считают владение за три года, а не цену запуска. Третий: веса критериев зависят от этапа бизнеса, поэтому платформа, которая подходила для проверки спроса, через два года может стать ограничением — и это нормальный повод пересмотреть выбор. Если вы уже на этом этапе, посмотрите разбор о переходе с коробочных решений на модульную платформу.

Команда — федеральная команда FITTIN с центром разработки в Воронеже.

Что делать дальше:

• Понять, где теряются заказы сейчас, — комплексный аудит интернет-магазина; оценить качество текущего решения — аудит кода.
• Зафиксировать сценарии и требования — разработка технического задания; посчитать бюджет — калькулятор стоимости и тарифы.
• Собрать магазин и мобильный канал — сайты для интернет-магазинов, мобильные приложения для e-commerce, комплексная разработка e-commerce; описать задачу — контакты.

Часто задаваемые вопросы

Какая платформа для интернет-магазина лучше?

Универсального ответа нет: всё зависит от этапа бизнеса. Для проверки спроса быстрее и дешевле всего арендованный конструктор. Для типового каталога при своей команде разработки подходит CMS с открытым кодом. Для растущего магазина с обменом с 1С и маркетплейсами, нестандартными сценариями заказа и мобильным приложением — модульная платформа или заказная разработка. Составьте список обязательных сценариев, проставьте веса критериям и сравните две-три платформы разных типов на своих данных.

Чем платформа для интернет-магазина отличается от CMS?

CMS — система управления содержимым: товары, страницы, баннеры, тексты. Платформа интернет-магазина шире: кроме управления содержимым она закрывает корзину и оформление заказа, оплату, личный кабинет, лояльность, обмен с учётной системой, службами доставки и маркетплейсами, а часто и мобильное приложение. Поэтому сравнивать платформы только по удобству панели управления недостаточно — важнее интеграции, каналы продаж и стоимость владения.

Можно ли начать на конструкторе, а потом перейти на другую платформу?

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

Сколько времени занимает запуск интернет-магазина на платформе?

Зависит от типа платформы. Типовую витрину на конструкторе запускают за 3–10 рабочих дней. Внедрение коробочной CMS с интеграциями занимает 20–40 рабочих дней, на открытом коде — 20–45. Интеграция модульной платформы под бренд — до 30 рабочих дней: настройка модулей, фирменный дизайн, подключение учётной системы, оплаты и доставки. Заказная разработка с нуля до первого выпуска — 120–250 рабочих дней. Сроки растут, если данные в текущей системе не приведены в порядок.

Нужна ли своя команда разработки после запуска магазина?

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

Как понять, что текущая платформа перестала подходить?

Признаки повторяются: нужный для продаж сценарий нельзя реализовать или его месяцами ждут от провайдера; счёт за платные расширения растёт; сайт тормозит в распродажи; данные тяжело выгрузить; сайт и приложение живут раздельно и акции заводят дважды; обновление движка ломает доработки. Три признака и больше — повод посчитать переход. Один-два — повод для точечной работы: доработки узкого места или редизайна без смены платформы.

Можно ли подключить 1С и маркетплейсы к любой платформе?

Технически почти к любой, разница в цене и сроках. Где-то интеграция с 1С, Wildberries, Ozon и Яндекс Маркетом уже готова и её настраивают, где-то её пишут заново и оценивают в часах. На конструкторе доступны только интеграции из каталога провайдера. Перед выбором сверьте список обязательных систем с готовыми интеграциями платформы и попросите оценку в часах для остальных — эта разница может составлять десятки рабочих дней.

Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.