На чём создать интернет-магазин: конструктор, CMS или кастомная разработка

Какие товары и сколько позиций будет в каталоге

Я смотрю на три вещи: сложность товара, ширину ассортимента и частоту изменений.

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

Ещё один маркер — структура. Один уровень категорий почти всегда прост. Несколько уровней и пересечения по атрибутам сразу поднимают требования к CMS и к базе данных.

Какие каналы продаж нужны: SEO, реклама, маркетплейсы, соцсети

Я уточняю, откуда вы хотите получать продажи в первые месяцы и через год.

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

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

Если вы продаёте через маркетплейсы и соцсети, я смотрю на выгрузки, остатки и единый учёт. Иначе вы начнёте путаться в ценах и наличии.

Какие процессы надо автоматизировать: склад, доставка, возвраты

Я считаю интернет-магазин не витриной, а процессом. И этот процесс почти всегда упирается в учёт и логистику.

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

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

Конструктор и SaaS-платформа

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

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

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

CMS с готовым модулем магазина

CMS я рассматриваю, когда вам нужен контроль над сайтом и контентом, и вы хотите развивать SEO. Тут у вас появляется свой хостинг и своя админка: вы ставите модуль магазина и настраиваете структуру каталога, фильтры и страницы под поиск.

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

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

Кастомная разработка на фреймворке

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

Плюс в том, что вы проектируете каталог, цены, скидки, роли и интеграции так, как нужно бизнесу. Плюс в скорости и стабильности, если сразу заложена правильная архитектура. Минус во входном пороге: нужно чёткое ТЗ, дисциплина в изменениях и план поддержки после запуска.

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

Для быстрого старта и простого ассортимента

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

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

Если вы на старте и не уверены в модели, конструктор часто даёт самый дешёвый тест. А когда появятся устойчивые продажи и понятные процессы, вы сможете перейти на CMS или на кастом без хаоса.

Ограничения по дизайну, функционалу и владению данными

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

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

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

По данным я смотрю на три зоны: каталог, клиенты, заказы. В SaaS данные обычно хранятся у сервиса; экспорт существует, но он не всегда полный и удобный — часто теряются связи (статусы, история оплат, источники заказа, поля в карточке клиента). Потом перенос на другую систему превращается в отдельный проект.

Что проверить до запуска: домен, платежи, выгрузки, доступы

Перед запуском на конструкторе я делаю короткую проверку — она экономит недели нервов.

Домен — кто владелец и где лежат доступы. Я фиксирую доступ к регистратору и почте администратора. Если домен оформлен на подрядчика, вы зависите от него.

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

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

Управление контентом и SEO-возможности

Сильная сторона CMS — это контент. Я могу построить структуру под спрос, создавать страницы категорий и подкатегорий, управлять текстами, блоками, перелинковкой и метаданными.

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

Ещё один плюс — контроль над посадочными страницами. Вы не ограничены только карточками и категориями: можно делать страницы под бренды, подборки и сценарии. Это помогает и SEO, и рекламе.

Зависимость от плагинов и обновлений

С CMS я всегда считаю риски через плагины. Почти любой магазин на CMS собирается из модулей: оплата, доставка, интеграции, SEO, кеширование, безопасность. Это нормально, но это система из деталей.

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

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

Для каких задач обычно выбирают WooCommerce, OpenCart, 1С-Bitrix

WooCommerce обычно выбирают, когда нужен магазин рядом с контентом: блог, статьи, посадочные, SEO-разделы и каталог в одной админке. Я вижу этот вариант у малого и среднего бизнеса, когда важно быстро начать и потом наращивать функции модулями. Но я сразу закладываю поддержку — без неё плагины и обновления начнут конфликтовать.

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

1С-Bitrix обычно выбирают, когда бизнес уже живёт в экосистеме 1С и хочет плотную связку с учётом: заказы, остатки, статусы, обмен данными. Также Bitrix берут компании, которым нужны строгие роли доступа и управляемость в админке. Но этот выбор требует дисциплины: нужен администратор, обновления и контроль производительности.

Нестандартная логика цен, скидок, ролей и личных кабинетов

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

• разные цены для разных групп клиентов
• B2B-условия и персональные прайсы
• скидки, которые зависят от бренда, категории, набора и истории покупок
• ограничения по ролям: оператор видит одно, менеджер другое, партнёр третье
• личные кабинеты, где клиент видит договоры, счета, статусы, возвраты и историю

На CMS это часто можно собрать, но потом начинается хрупкость: один модуль тянет второй, и вы всё равно упираетесь в границы логики.

Сложные интеграции и требования к скорости

Я выбираю кастом, когда интеграции решают бизнес-задачу каждый день. Типовые примеры:

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

Тут я смотрю на архитектуру: заранее проектирую, где хранится правда по остаткам и ценам, кто управляет статусами заказа и как система переживёт пик нагрузки.

Риски кастома: сроки, поддержка, требования к документации

У кастома есть цена, и я всегда называю её прямо.

Сроки — вы не запускаетесь за пару дней, а проходите анализ, проектирование, разработку и тестирование. Если меняете требования по ходу, сроки растут.

Поддержка — магазин живёт после релиза: ошибки, обновления, новые интеграции, улучшения UX. Если вы не планируете поддержку, кастом быстро станет дорогим во владении.

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

SEO и контент: фильтры, ЧПУ, индексация, скорость

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

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

ЧПУ — я проверяю, как строятся адреса категорий, подкатегорий и карточек. Мне нужен понятный URL и стабильная структура, чтобы адреса не менялись после правки категории или импорта. Индексация — robots.txt, sitemap.xml и правила для дублей (варианты товара, сортировки, параметры, поиск по сайту).

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

Конверсия и UX: поиск, карточка товара, оформление заказа

Я считаю UX главным рычагом в e-commerce. Один и тот же трафик может давать разный результат, если магазин неудобен.

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

Карточка товара — как показываются цена, наличие, варианты и доставка. Клиент должен понять товар за минуту: фото, характеристики, отзывы, условия возврата и понятная кнопка «купить». Если карточка размывает ответ, конверсия падает даже при хорошем дизайне.

Оформление заказа — я считаю шаги до оплаты и убираю лишнее. Я не заставляю регистрироваться до покупки, если это не B2B, проверяю, как платформа ведёт клиента после ошибки оплаты и как сохраняет корзину, и смотрю оформление на телефоне. В Казахстане мобильный трафик почти всегда доминирует, и слабый чекаут убивает рекламу.

Безопасность и стабильность: обновления, бэкапы, роли доступа

Я воспринимаю интернет-магазин как операционную систему. Он не имеет права падать, когда у вас идёт реклама и заказы.

Обновления — кто и как обновляет ядро, тему и плагины. В CMS без обновлений вы копите уязвимости, в SaaS зависите от сервиса, в кастоме — от своей дисциплины релизов. В любом варианте нужен процесс.

Бэкапы — где лежат резервные копии и как быстро вы восстановитесь. Я отдельно проверяю бэкапы базы данных, потому что заказы и клиенты важнее картинок. Без понятного восстановления любой сбой превращается в простой и потерю денег.

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

Онлайн-оплата: что важно для подключения и фискализации

Я сначала выясняю, где вы зарегистрированы и как сейчас принимаете деньги. Это влияет на способ подключения и на то, кто отвечает за чек и отчётность.

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

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

Доставка: тарифы, трекинг, пункты выдачи и расчёты на чекауте

Я смотрю на доставку как на часть продаж. Клиент принимает решение в корзине: если он не понимает стоимость, срок и условия, он закрывает вкладку.

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

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

Учёт и CRM: 1С, склад, статусы заказов и уведомления

Я всегда задаю один вопрос: где у вас источник правды по остаткам и ценам. Если это 1С или складская программа, сайт не должен жить отдельной жизнью.

Я проверяю, что именно вы хотите синхронизировать: номенклатуру и характеристики, остатки по складам, цены и скидки, резервы, статусы заказа, документы. Если не определить это заранее, интеграция начнёт расползаться и ломать процессы.

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

Если вы хотите, я могу посмотреть ваш текущий набор требований и сказать, выдержит ли его конструктор или CMS, или вам уже нужен кастом. Для разработки интернет-магазина под ваш процесс логично идти на страницу услуги Qazaqsoft по созданию интернет-магазина под ключ в Алматы и Казахстане.

Магазин упирается в скорость и ограничения платформы

Сначала магазин работает нормально. Потом растёт каталог, фильтры, фото и трафик — и вы начинаете ловить тормоза, особенно на мобильных и на чекауте.

В конструкторах и SaaS вы часто не можете исправить причину, только смягчить симптомы. В CMS можно оптимизировать, но иногда вы упираетесь в ядро, плагины и архитектуру темы.

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

Интеграции становятся критичными для операционки

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

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

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

Нужны масштабирование, роли, B2B-функции и гибкие цены

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

• разные цены для разных клиентов и договоров
• персональные скидки и прайсы
• оптовые условия и минимальные партии
• отсрочка платежа и счета
• личный кабинет B2B-клиента с документами и повтором заказа
• роли внутри компании клиента, где один оформляет, другой согласует

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

Структура каталога и атрибуты товаров

Каталог — это не список. Это ваша будущая навигация, фильтры и SEO. Я сначала фиксирую структуру: категории и подкатегории, пересечения (если один товар живёт в нескольких ветках), бренды, коллекции, серии.

Потом я описываю атрибуты:

• характеристики для фильтров
• варианты товара: размер, цвет, объём
• единицы измерения
• артикулы и штрихкоды, если они важны для учёта
• фото и правила для изображений

И ещё один пункт, который часто забывают — что считать уникальным товаром. Если вы ошибётесь здесь, потом будете переделывать импорт, фильтры и карточки.

Правила ценообразования, скидок и доставки

Я всегда прошу бизнес описать правила на бумаге — не в голове и не в переписке по кускам.

Цены: одна или несколько типов цен, цена по складу или общая, с НДС или без, округление и валюта. Скидки: от суммы, по промокоду, по группе клиента, на категорию или бренд, правила совместимости (можно ли суммировать).

Доставка: зоны и города, порог бесплатной доставки, ограничения по весу и габаритам, самовывоз и пункты выдачи, расчёт до оплаты и отображение срока.

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

Аналитика и события: что измерять с первого дня

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

Я бы измерял воронку покупки (просмотр категории, просмотр карточки, добавление в корзину, переход в оформление, выбор доставки и оплаты, успешная оплата) и качество трафика по каналам (SEO, реклама, соцсети, маркетплейсы — не только заказы, но и поведение).

Отдельно я фиксирую ошибки и сбои: ошибки оплаты, ошибки доставки и расчёта суммы, 404-страницы и проблемы с фильтрами, сохранение корзины после ошибки. И бизнес-метрики, которые влияют на решения: средний чек, повторные покупки, доля отмен и возвратов, время обработки заказа.

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