Стоимость интернет-магазина зависит от того, какой путь проходит заказ: от выбора конкретного товара до оплаты, передачи в учёт и подготовки к выдаче. Смета должна описывать этот путь вместе с работой сотрудников, исходными данными и проверкой результата.
У Студии Вебирус стартовая стоимость интернет-магазина — от 149 000 ₽. По согласованному прайсу на 3 октября 2026 года это базовый каталог, корзина и оформление заказа. Онлайн-оплата, доставка, импорт товаров и обмен с внешними системами выделяются в смете. Число товаров само по себе не определяет итоговую цену: важно, как устроены данные и какие действия с ними нужны.
Что стоит за базовым каталогом, корзиной и заказом
Стартовая цена относится к ограниченному составу. До оценки нужно договориться, что именно сможет сделать покупатель и как магазин получит его заказ. Формулировка «каталог и корзина» без этих границ оставляет слишком много неизвестного.
| Часть магазина | Что зафиксировать для оценки | Что может расширить работу |
|---|---|---|
| Каталог | Категории, способ поиска и отбора, согласованные типы карточек | Разные наборы характеристик, подбор совместимых товаров, дополнительные шаблоны |
| Варианты товара | Какие исполнения покупатель выбирает и как они связаны с ценой и доступностью | Отдельные изображения, остатки и правила для сочетаний размера, цвета или комплектации |
| Корзина | Изменение количества, удаление позиции, состав и сумма заказа | Комплекты, ограничения количества, скидочные правила, разные условия для покупателей |
| Оформление заказа | Нужные данные покупателя, способы получения и последовательность подтверждения | Разделение заказа на отправления, разные склады, дополнительные проверки |
| Управление | Кто меняет товары и условия, где сотрудник видит заказ и какие действия выполняет | Несколько ролей, согласование изменений, индивидуальные рабочие процессы |
| Дизайн и отображение | Шаблоны, адаптивность и состояния, которые входят в результат | Новые типы страниц и дополнительные состояния, требующие отдельного проектирования |
Каждая продаваемая комбинация опций требует внимания. Например, в учебном магазине полотенце одного размера в синем цвете и то же полотенце в жёлтом — разные варианты выбора. Если доступность ведётся по вариантам, корзина и заказ должны сохранять именно выбранное исполнение. Одного общего изображения и названия модели для такого сценария недостаточно.
Количество позиций влияет на объём наполнения, обработки данных и проверки работы каталога, но не заменяет оценку. Большой однородный каталог из подготовленного файла и меньший ассортимент с неполными характеристиками требуют разной работы. Попросите отдельно показать создание механизма каталога и размещение конкретного объёма товаров: это две разные задачи.
Если нужны персональные цены, оптовые ограничения или согласование заказа, их следует описать до расчёта. Такие требования могут привести к отдельному B2B-кабинету, а не к небольшой правке обычной корзины.
Интеграции оценивают по результату, а не по названию сервиса
Строка «подключение оплаты» или «интеграция с 1С» не показывает границы работ. Для каждой связи нужны система, данные, направление передачи, условия запуска и действия при ошибке. Также важно определить, кто предоставляет доступы и кто выполняет работы на стороне внешней системы.
Онлайн-оплата: подтвердить результат и связать его с заказом
В смету стоит включить выбранный способ приёма оплаты, передачу суммы и состава заказа, получение подтверждённого статуса, поведение при отмене и незавершённой оплате. Возвраты и передачу данных для чеков нужно описать отдельно, если они входят в согласованный процесс.
Переход покупателя обратно на сайт после оплаты не заменяет проверку результата. Например, ЮKassa передаёт серверные уведомления о статусах платежей и возвратов; их подлинность и актуальность следует проверять, а доставка уведомления может повторяться. Поэтому нужно проверить, что один платёж связан с нужным заказом и повторное событие не запускает повторное исполнение.
Комиссия провайдера и работа разработчика по подключению — разные расходы. Подготовка кабинета, реквизитов и условий обслуживания также не равна технической интеграции. Если используются чеки, их настройку и проверку согласуют с ответственным за расчёты и выбранным провайдером; универсальный состав нельзя вывести из одной кнопки «Оплатить».
Доставка: расчёт тарифа и создание отправления — разные задачи
Сначала определите, что должен делать сайт: показывать условия самовывоза, рассчитывать стоимость перевозки, давать выбор пункта выдачи или ещё и создавать отправление с передачей данных оператору. Последний вариант содержит дополнительную работу после оформления заказа.
Для внешнего расчёта могут потребоваться точка отправления, адрес или пункт получения, способ доставки и весогабаритные данные. Например, метод предварительной оценки Яндекс Доставки принимает параметры заказа и грузовых мест. Отсутствующие размеры упаковки нельзя компенсировать точной настройкой интерфейса: сначала нужны достоверные исходные данные.
В оценке зафиксируйте поведение при недоступном тарифе или сбое сервиса. Магазин не должен превращать ошибку расчёта в бесплатную доставку. Возможный путь — оставить заказ на согласование стоимости с менеджером, но это отдельное бизнес-решение, которое нужно принять до разработки.
Импорт товаров: подготовка файла, загрузка и последующие обновления
Первоначальная загрузка готового каталога может включать согласование полей, сопоставление категорий и вариантов, проверку файла, перенос изображений и сверку результата. Исправление исходных названий, поиск отсутствующих фото и заполнение характеристик — другая работа. Укажите её исполнителя и объём.
Если файл будут загружать повторно, нужно определить, по каким идентификаторам находятся существующие товары, какие поля обновляются и что происходит с отсутствующей строкой. Иначе первый успешный импорт ничего не говорит о безопасном обновлении каталога.
Не учитывайте первоначальную загрузку дважды. Если стартовое наполнение уже выполняется через интеграцию с учётной системой, отдельная строка импорта должна описывать только дополнительную работу: например, очистку исходных данных или перенос материалов, которых нет в учёте.
Обмен с 1С: отдельно товары и отдельно заказы
Официальный протокол обмена с сайтом разделяет публикацию каталога, цен и остатков и обмен информацией о заказах. Поэтому фраза «товары выгружаются из 1С» не подтверждает, что заказы с сайта поступают обратно и их статусы согласованы.
Для оценки нужны название и версия конфигурации, сведения о её изменениях, доступный способ обмена и проба реальных данных без чувствительных сведений. По каждому полю определите источник: где ведут цену, остаток, описание, изображения и статус заказа. Затем согласуйте периодичность обновления и порядок восстановления после сбоя.
Работы на сайте и в 1С могут выполнять разные специалисты. В смете должна быть понятна ответственность за обе стороны и общая проверка обмена. Готовый стандарт не подтверждает совместимость конкретной конфигурации и не определяет правила резервирования товара за ваш бизнес.
Материалы и работа команды тоже входят в оценку
Даже при готовом программном каталоге нужно подготовить сведения, которыми он будет наполнен. Для сметы полезен не только список категорий, но и образцы разных типов товара: простой позиции, варианта, комплекта и товара с особыми условиями, если они есть в ассортименте.
До оценки соберите:
- названия, идентификаторы, характеристики и связь вариантов с основной моделью;
- цены и правила доступности, сведения об источнике и обновлении этих данных;
- фотографии и описания с понятным объёмом подготовки;
- условия покупки и получения, контактные данные и необходимые документы;
- перечень действий сотрудника с заказом и нужные уведомления;
- сведения о внешних системах и ответственном за каждую из них.
Нужно различать написание описаний, обработку изображений и размещение готовых материалов. Запись «наполнение включено» должна отвечать, какие именно действия и какой объём покрывает цена.
Обсуждение требований, проектирование, управление работой, проверка и выпуск — части разработки. В предложении они могут находиться в общей цене или отдельных строках. Проверьте, что они учтены и не начислены повторно внутри другого этапа. Например, «подключение доставки с проверкой» и общая строка тестирования должны описывать согласованное распределение работ.
Два учебных состава для одного типа магазина
Ниже — условный магазин товаров для дома. Примеры показывают различие объёмов, а не готовые пакеты Студии Вебирус. У них нет назначенной цены или срока: даже первый состав нужно сопоставить с границами стартового предложения.
Состав А: заказ на самовывоз с ручным подтверждением
Покупатель выбирает товар и его цвет, добавляет позиции в корзину и оформляет заказ на самовывоз из одной точки. Сотрудник проверяет доступность и подтверждает заказ. Оплата выполняется при получении; онлайн-эквайринг в этом учебном составе не подключается.
Смета должна описывать категории и согласованный отбор товаров, выбор исполнения, корзину, форму заказа, получение заказа сотрудником и изменение его состояния. Отдельно фиксируются первоначальное размещение подготовленных товаров, настройка информации о самовывозе, обучение работе с заказами и проверка на телефоне и компьютере.
Каталог, цены и доступность сотрудник ведёт вручную. Значит, бизнесу нужно назначить ответственного за обновление. Отсутствие автоматического обмена уменьшает состав интеграций, но сохраняет эту ежедневную работу.
Состав Б: оплата и доставка с обменом данными
Покупатель выбирает исполнение товара, оформляет заказ, оплачивает его онлайн и выбирает доступный способ доставки. Цены и остатки приходят из 1С, заказы передаются обратно. Сотрудник работает с согласованными статусами заказа.
Помимо каталога и пути оформления в смете появляются:
- подключение оплаты, подтверждение статуса и согласованные сценарии возвратов и чеков;
- выбор способа получения, расчёт доставки и, если требуется, создание отправления;
- обмен товарами, ценами и остатками, передача заказов и согласование статусов;
- первоначальная загрузка через этот обмен и отдельная подготовка недостающих материалов;
- контроль сбоев, повторной передачи данных и восстановления работы;
- совместная проверка сайта, учётной системы и внешних сервисов.
Перед оценкой нужно решить, где и в какой момент резервируется товар, что делать с неоплаченным заказом и как отражать отмену. Эти решения влияют на несколько частей сразу. Их нельзя оставлять независимыми настройками каждого модуля.
Разница между составами связана с данными, автоматизацией и ответственностью систем. Состав Б не получается из состава А простым добавлением двух кнопок. При этом регулярные платежи за сервисы нельзя включать в стоимость разработки без указания периода и затем прибавлять их повторно к бюджету работы магазина.
Как проверить, что смета покрывает рабочий магазин
Для приёмки нужны условия, по которым можно показать готовность. Названия модулей недостаточны. Вместе с исполнителем составьте набор сценариев на ваших товарах и правилах:
- Покупатель выбирает конкретный вариант; в корзине, заказе и системе учёта сохраняется именно он.
- Изменение количества или удаление позиции даёт правильный состав и итог. Изменение цены или доступности до подтверждения обрабатывается по согласованному правилу.
- Повторное нажатие при отправке не создаёт лишний заказ. Ошибка формы не теряет уже введённые данные без необходимости.
- Успешная, отменённая и незавершённая оплата различимы. Проверенное повторное уведомление не вызывает повторного исполнения.
- Для выбранного адреса или пункта получения доступны только подходящие условия. Сбой расчёта не подменяет стоимость доставки нулём.
- Повторный импорт или обмен не создаёт дубли. Ошибка видна ответственному, а порядок исправления и возобновления понятен.
- Сотрудник может найти заказ, проверить выбранные товары и выполнить согласованные действия; основные сценарии доступны на нужных устройствах.
Применяйте только пункты, относящиеся к вашему составу. Их проверку нужно учитывать в оценке. Если связанный сценарий проходит через сайт, оплату, доставку и 1С, одной проверки каждого подключения по отдельности недостаточно.
Тестовая операция также имеет границы. Например, ЮKassa в режиме проверки чеков имитирует взаимодействие с онлайн-кассой: физический чек не формируется. Уточните, какие результаты подтверждены тестовой средой и что проверяют при переходе в рабочую.
Расходы после запуска: сервисы, поддержка и развитие
После создания магазина бюджет зависит от выбранных условий обслуживания и фактического использования. Отдельно от разработки запишите:
| Расход | Что уточнить | Как избежать повторного учёта |
|---|---|---|
| Домен и размещение | Период оплаты, состав ресурсов и ответственного за продление | Если часть периода входит в запуск, указать её и дату следующего платежа |
| Внешние сервисы | Комиссии оплаты, условия сервиса чеков, доставки и уведомлений | Разделить работу по подключению, подписку и оплату по использованию |
| Техническая поддержка | Какие действия и объём работ входят в договор | Не прибавлять отдельно часы, уже включённые в пакет |
| Наполнение и развитие | Кто обновляет ассортимент и какие новые функции планируются | Отличать текущую работу с данными от изменения программного поведения |
Стоимость перевозки отдельного заказа и плата за работу транспортной интеграции также имеют разную природу. Укажите, какую часть оплачивает покупатель, какую несёт магазин и какие платежи зависят от числа операций. Без условий провайдеров общую ежемесячную сумму определить нельзя.
В согласованном прайсе Студии Вебирус поддержка начинается от 6 000 ₽/мес. и включает до трёх часов работ, в том числе коммуникацию, проверку и выпуск изменений. Дополнительные часы предварительно согласуются по 2 000 ₽/час. Это не обещание неограниченного обслуживания; наполнение, наблюдение за обменом и другие нужные действия следует явно согласовать.
Для отдельного разового заказа действуют другие условия: 3 000 ₽/час, минимальный заказ — один час; объём и стоимость оцениваются до начала работы. Не переносите эту ставку автоматически на всю разработку нового магазина и не смешивайте её с дополнительными часами поддержки. Актуальные составы и условия собраны в ценах на разработку и поддержку сайтов.
Что отправить для предметной оценки
Опишите путь покупки, приложите образцы товарных данных и перечислите необходимые системы. Для каждого требования отметьте результат, исходные материалы и ответственного. Если решение ещё не принято, сохраните его как вопрос для оценки: неизвестное не должно незаметно превращаться в включённую функцию.
В ответном предложении должны быть итоговый состав, цена, исключения, условия изменения объёма и проверяемые результаты. Для разработки интернет-магазина отправной точкой служат каталог, корзина и заказ; окончательная смета появляется после согласования деталей. Если за ними стоят индивидуальные процессы, выбор платформы лучше обсудить отдельно — этому посвящён материал о том, когда магазину подходит Laravel.
