Сколько стоит интернет-магазин с 1С, складом и CRM

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

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

Цены Like Sites в тексте приведены как условия Like Sites на дату проверки, 31 октября 2026 года, а не как среднерыночные значения. Средних цен по рынку в статье нет намеренно: без единой методики подсчёта они вводят в заблуждение.

Что сравнивать: каталог, MVP или полноценный магазин?

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

На странице раздела интернет-продаж Like Sites эта лестница описана как три уровня: «быстрый старт» с небольшим каталогом и типовыми процессами, «собственный D2C-магазин» со складом, остатками, оплатой, доставкой и CRM и «торговая система B2B + B2C» с ролями, кабинетами и несколькими складами; ориентир стоимости интернет-магазина на текущих условиях — от 199 000 ₽ (страница «Интернет-продажи»). Отдельная страница «Разработка интернет-магазина» того же сайта указывает базовый магазин на React с каталогом, корзиной, онлайн-оплатой, расчётом доставки и SEO от 149 000 ₽ со сроком 4–8 недель и технической поддержкой 60 дней (страница «Интернет-магазин»).

Разница между 149 000 и 199 000 ₽ на одном сайте — наглядная иллюстрация главного тезиса. Первая цена относится к магазину как к сайту с оплатой и доставкой. Вторая — к магазину как к каналу продаж, связанному со складом, учётом и CRM. Это разные проекты, и путать их при сравнении предложений нельзя.

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

Какие функции определяют трудоёмкость?

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

Функции, которые добавляют трудоёмкость сильнее, чем кажется заказчику:

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

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

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

Сколько работы скрывается в товарных данных?

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

Работа с данными, которую придётся оплатить — деньгами подрядчику или временем своих сотрудников:

1. Проектирование структуры каталога. Категории, подкатегории, набор характеристик по каждому типу товара, единицы измерения, обязательные и необязательные поля.
2. Нормализация характеристик. Приведение значений к единому виду: «красный», «Красный» и «red» — один цвет; «1,5 м» и «150 см» — одна длина.
3. Сопоставление идентификаторов. Внутренний артикул, штрихкод, артикулы площадок, код в учёте — таблица соответствий, без которой обмен остатками невозможен.
4. Подготовка контента. Описания под покупателя сайта, а не под фильтры площадки; обязательная информация о товаре по закону; права на фото и тексты.
5. Обработка изображений. Оригиналы, единый формат, размеры, alt-тексты, сжатие без потери качества.
6. Проверка после загрузки. Сколько карточек и вариантов было в источнике, сколько получилось на сайте, почему есть разница.

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

Поэтому первый вопрос подрядчику, который называет цену без запроса выгрузки товаров: «Что вы предполагаете о состоянии наших данных?» Если ответ — «что они готовы», в смете нет самой дорогой части проекта.

Как интеграции влияют на бюджет?

Интеграция — это не «подключить модуль». Это договорённость о том, какая система владеет каждым полем, передача данных с обработкой ошибок, журнал и тестовый контур. Стоимость каждой интеграции определяется не количеством товаров, а конфигурацией систем клиента и составом передаваемых данных.

Страница Like Sites об интеграции с 1С прямо формулирует принцип: стоимость интеграции определяется конфигурацией клиента, а не количеством товаров, поэтому фиксированной цены до обследования не существует; на оценку влияют конфигурация и доработки, доступный интерфейс обмена, состав передаваемых данных, качество данных в учёте, требования к частоте обмена и к наблюдаемости (страница «Интеграция интернет-магазина с 1С»). Это честная позиция, и её стоит требовать от любого подрядчика: если в коммерческом предложении интеграция с 1С стоит фиксированную сумму без обследования, значит, либо объём работ ограничен типовым сценарием, который может вам не подойти, либо риск заложен в цену с запасом.

Отдельно о порядке. Интеграции не оцениваются «пакетом» — у каждой свои зависимости. Обмен с учётом нужен раньше CRM: без достоверных остатков и заказов CRM получает мусор. Оплата с кассой — до запуска рекламы. Доставка — вместе с оплатой, потому что чеки зависят от схемы передачи товара. Как устроена схема единых остатков для магазина, который продаёт со своего склада и через площадки, описано на странице интернет-магазин с собственным складом; какие события заказа и обращения нужно передавать, чтобы CRM работала на повторные продажи, — на странице интеграция магазина с CRM.

Какие расходы разовые, а какие регулярные?

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

Разовые расходы:

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

Регулярные расходы:

• Хостинг или сервер, домен, SSL-сертификат.
• Комиссия платёжного оператора с каждого заказа.
• Подписки: CRM, облачная касса, складской сервис, сервис доставки, почтовые рассылки, аналитика.
• Техническая поддержка: мониторинг, резервные копии, исправления, обновления.
• Развитие: новые функции, страницы, интеграции, SEO-работы.
• Привлечение покупателей: реклама, контент, работа с поиском.
• Операционные расходы: сборка, упаковка, доставка, обработка возвратов, время менеджеров.

Пример регулярной статьи, которую легко недооценить, — эквайринг. ЮKassa на своей странице тарифов указывает комиссию 2,8% плюс 1% за чек при приёме банковских карт, SberPay, T-Pay и других способов при условии подключения сервиса «Чеки от ЮKassa»; комиссия указана без НДС, тариф по СБП рассчитывается индивидуально, а само предложение действует для новых контрагентов с 28 января по 1 декабря 2026 года (тарифы ЮKassa). Для магазина с оборотом 1 000 000 ₽ в месяц через карты это порядка 38 000 ₽ комиссии ежемесячно до НДС — арифметика по опубликованному тарифу, не прогноз. У других операторов и на других условиях цифры иные, но порядок величины показывает: платёжная комиссия за год может превысить стоимость части разработки.

Второй пример — касса. При онлайн-оплате продавец обязан применять контрольно-кассовую технику и формировать чек покупателю в электронном виде; требования установлены Федеральным законом № 54-ФЗ (актуальная редакция). Это означает облачную кассу с арендой, фискальный накопитель и договор с оператором фискальных данных — три регулярных платежа, которые к разработке сайта не относятся, но без которых магазин не имеет права принимать оплату.

Когда подходит CMS, конструктор или индивидуальная разработка?

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

Like Sites на странице раздела описывает три варианта — готовую e-commerce-платформу для быстрого запуска и MVP, индивидуальный магазин на React и SSG для брендов и сложных каталогов и B2B-портал с ролями и кабинетами — и отдельно оговаривает, что не предлагает индивидуальную разработку там, где задачу надёжно решает готовая платформа (страница «Интернет-продажи»). Это правильный критерий: индивидуальная разработка оправдана, когда у вас есть процессы, которые платформа не умеет, а не когда хочется «свой уникальный сайт».

Простой тест. Если вы можете описать свой магазин словами «каталог, корзина, карта, СБП, СДЭК, самовывоз» и у вас один склад и один тип цены — начинайте с платформы или MVP, деньги на индивидуальную разработку сейчас не вернутся. Если в описании появляются «обмен с нашей 1С УТ с доработками», «три склада и резервы», «оптовые цены для дилеров», «пятнадцать тысяч SKU с вариантами» — платформа упрётся в ограничения через полгода, и переезд обойдётся дороже, чем сразу построить под задачу.

Как составить бюджет первого года?

Бюджет первого года — главный инструмент принятия решения. Он показывает не «сколько стоит сайт», а сколько денег потребует канал продаж до того, как начнёт возвращать вложения. Ниже — шаблон. Заполняйте его по своим данным и предложениям подрядчиков; цифр в нём намеренно нет.

Три правила заполнения:

1. Регулярные расходы считайте с месяца запуска, а не с месяца первых продаж. Хостинг, касса и CRM стоят денег и в период, когда заказов мало.
2. Комиссию оператора и доставку считайте от планового оборота, а не от разовой суммы. Это переменные расходы, и при росте продаж они растут.
3. Резерв на развитие закладывайте обязательно. После запуска всегда появляются задачи, которых не было в ТЗ: новый способ доставки, отчёт, правило акции. Магазин без бюджета на развитие через год устаревает.

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

Что должно быть в ТЗ и смете?

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

Обязательные разделы технического задания и сметы для магазина с интеграциями:

1. Тип проекта и его границы. Каталог, MVP, полноценный магазин или торговая система — словами, с перечнем того, что не входит.
2. Структура каталога. Число категорий, типов товаров, характеристик; правила вариантов и комплектов; кто готовит данные и в каком формате.
3. Пользовательские сценарии. Поиск, карточка, корзина, оформление, оплата, доставка, личный кабинет, возврат — каждый с описанием состояний и исключений.
4. Интеграции. По каждой: системы и версии, объекты и направление передачи, частота, поведение при ошибке, журнал, тестовый контур, кто предоставляет доступы.
5. Роли и права. Кто что видит и может менять на сайте и в административной части.
6. SEO-требования. Структура адресов, метаданные, Schema.org, карта сайта, индексируемость, редиректы при миграции.
7. Нефункциональные требования. Скорость, адаптивность, доступность, резервные копии, мониторинг.
8. Данные и контент. Что предоставляет клиент, в каком виде, к какому сроку; что делает подрядчик.
9. Этапы и критерии приёмки. Что считается готовым на каждом этапе и как это проверяется.
10. Права на результат. Кому принадлежат код, дизайн, данные; что передаётся при завершении сотрудничества.
11. Поддержка после запуска. Что входит в гарантийный период, что — в платную поддержку, время реакции.
12. Таблица «входит / отдельно / отложено». Явный список функций в трёх колонках.

Последний пункт стоит сделать отдельным документом и подписать обеими сторонами. Вот пример структуры такой таблицы для магазина с 1С, складом и CRM:

Состав колонок у вас будет свой. Важен принцип: ни одна обсуждавшаяся функция не должна остаться без отметки.

Какие функции можно отложить?

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

Откладывать нельзя:

• Единый источник остатков и резервы. Без них магазин продаёт то, чего нет, с первого дня.
• Оплату с корректными чеками. Нарушение требований к кассе — не технический долг, а риск для бизнеса.
• Передачу заказов в учёт. Ручной перенос работает неделю, потом начинаются ошибки в артикулах и количествах.
• Обязательную информацию о товаре и порядке возврата. Это требование закона, а не функция.
• Базовую SEO-структуру адресов и каталога. Переделывать её после индексации дорого.

Откладывать можно:

• Обратные статусы из учёта на сайт, если на старте менеджер готов уведомлять покупателей вручную при небольшом потоке.
• Второй и последующие склады, пока работает один.
• Дополнительные службы доставки сверх одной основной и самовывоза.
• Триггерные сценарии в CRM: брошенная корзина, напоминания о повторной покупке. Для них сначала нужны данные.
• Личный кабинет покупателя с историей заказов — если нет повторных покупок, он пустует.
• Оптовый контур, если оптовые клиенты пока обслуживаются менеджером.
• Расширенную аналитику и отчёты.

Условие поэтапности — архитектура, которая позволяет добавить отложенное без переделки. Это нужно зафиксировать в ТЗ: «второй склад и оптовые цены не входят в первый этап, но структура данных и каталога должна допускать их добавление без миграции». Если подрядчик не может это гарантировать, экономия на первом этапе обернётся переделкой на втором.

Как сравнить два коммерческих предложения?

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

Порядок сравнения:

1. Приведите оба предложения к одной таблице «входит / отдельно / отложено». Если в одном КП нет пункта, который есть в другом, запросите явный ответ: входит, не входит или стоит отдельно.
2. Проверьте допущения о данных. Что подрядчик предполагает о состоянии каталога, характеристик, фото, идентификаторов. Кто и за чей счёт приводит данные в порядок.
3. Проверьте допущения об интеграциях. Названа ли цена интеграции с 1С до обследования конфигурации. Если да — спросите, какой сценарий заложен и что будет, если ваша конфигурация в него не укладывается.
4. Посчитайте регулярные расходы по каждому варианту. Платформа с подпиской и процентом от оборота против индивидуальной разработки с поддержкой по договору — за три года картина может быть противоположной разовой.
5. Сравните критерии приёмки. «Сдача магазина» и «сквозной тестовый заказ с оплатой, чеком, записью в учёте и CRM, отменой и чеком возврата» — разные вещи.
6. Сравните условия поддержки. Срок гарантии, что в неё входит, время реакции, стоимость часа доработок.
7. Сравните права. Кому принадлежат код и данные, можно ли передать проект другой команде, что вы получите при расторжении.
8. Задайте один вопрос про риск: «Что в этом проекте вы считаете самым неопределённым и как это учтено в цене?» Ответ «ничего, всё типовое» при наличии 1С с доработками и нескольких складов — сигнал, что риск не учтён и всплывёт в виде дополнительных счетов.

Чего не стоит делать: выбирать по портфолио «красивых сайтов». Магазин с интеграциями оценивается по тому, как подрядчик проектирует обмен данными, остатки и обработку ошибок, а не по витрине.

Когда магазин с интеграциями не нужен?

Честный ответ экономит больше денег, чем любая скидка. Полноценный магазин с 1С, складом и CRM не нужен, если:

• Нет причины прямого заказа. Типовой товар по той же цене, что на маркетплейсе, покупатель закажет на маркетплейсе. Сначала решается вопрос предложения, потом — разработки.
• Нет источника первых покупателей. Сайт без аудитории, рекламы и поисковой структуры — инфраструктура без трафика. Like Sites на странице раздела прямо пишет, что не обещает бесплатный поток заказов после публикации и что план привлечения должен быть частью проекта (страница «Интернет-продажи»).
• Маржа не покрывает привлечение и обработку заказа. Тогда регулярные расходы первого года превратят канал в убыток независимо от качества разработки.
• Учёт не ведётся системно. Если остатки в таблицах, а не в 1С или складском сервисе, интегрировать нечего: сначала учёт, потом обмен.
• Некому обрабатывать заказы. Сборка, отправка, возвраты, ответы покупателям — операционная нагрузка, которую сайт не снимает.
• Объём не оправдывает систему. Десять заказов в месяц обрабатываются вручную дешевле, чем обслуживается интеграция с учётом.

В этих случаях разумнее сайт-каталог с запросом, MVP на готовой платформе или вообще отсрочка проекта до появления аудитории и операционной готовности. Это не отказ от собственного канала, а правильная последовательность.

Какие данные подготовить для оценки?

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

1. Выгрузку товаров со структурой вариантов и характеристик; общее число SKU и число для первого этапа.
2. Учётную систему: название, конфигурацию и версию 1С или тариф МоегоСклада, перечень доработок, контакт специалиста, который её сопровождает, возможность тестовой копии.
3. Схему склада: число складов, FBS или FBO по площадкам, кто и где ведёт остатки сейчас.
4. Текущие каналы продаж и объём заказов по каждому.
5. CRM, если есть: название, тариф, что в неё сейчас попадает.
6. Платёжного оператора и кассу, если уже подключены; способы оплаты, которые нужны.
7. Службы доставки и регионы; есть ли самовывоз и собственные курьеры.
8. Существующий сайт, если есть: адрес, платформу, число страниц с трафиком.
9. Источники контента: оригиналы фото, договоры на съёмку и тексты.
10. Ограничения: бюджет первого года, сроки, сезонность, планы по опту и регионам.

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