Интернет-магазин на своём коде перестал быть роскошью: что меняется, когда его собирают агенты

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

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

Нижний порог прайса ещё не описывает ваш магазин. ИВИТ указывает «от 200 000 ₽» в заголовке страницы, а в теле предлагает индивидуальный расчёт на CMS.

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

Оптовые цены сами по себе не требуют своего магазина. InSales в обновлении тарифов 2026 года перечисляет типы цен, работу со складами и API для связи с другими системами.

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

Инженер ведёт машину агентов и принимает её работу. Агент готовит изменение по записанной задаче, инженер сверяет результат с правилами бизнеса.

Наше доказательство такого способа работы находится на /open. Машина ведёт этот сайт; его объём нельзя переводить в срок или скидку для вашего магазина.

Сравнение с командой на /open показывает модель затрат. ×8 относится к стоимости замещения нашей машины командой на нашем сайте, а не к цене магазина.

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

Повтор сообщения является частью протокола. Документация ЮKassa описывает повторную доставку; обработчик магазина должен узнавать уже обработанный платёж.

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

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

Приёмку записывают как наблюдаемый результат. «Сделать оплату» оставляет пробелы; «повтор уведомления не создаёт новый заказ» уже можно проверить.

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

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

Границу запуска задаёт порядок продажи. Для розницы это платёж и отгрузка; для опта первый запуск может принимать заявку, которую подтверждает менеджер.

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

Подписка подходит магазину, которому нужны следующие изменения. На /services «Один проект» стоит 250 000 ₽ в месяц: один продукт и один поток работы.

Магазин, оплата и доработки идут в этом потоке по очереди. Цена месяца не обещает закончить магазин за месяц; бюджет зависит от объёма и оплаченного времени.

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

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

Наблюдение должно возвращаться в следующую задачу. Если заказ потерял письмо, инженер исправляет обработку и добавляет проверку сбоя перед следующим выпуском.

Сообщения «у нас всё работает» для приёмки мало. Нужна связь заказа с оплатой и отгрузкой, по которой сотрудник разбирает расхождение.

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

Детали вынесены в соседние разборы: данные покупателей и связь с внутренней CRM. Выбор основы магазина эти вопросы не отменяет.

В курсе агентной разработки есть уроки «Клиенты», «Платёжки в России», «Касса на фантиках», «Боевая касса». Это работа с оплатой, а не кейс товарного магазина.

1. Выбирайте основу по пути заказа. Если платформа его закрывает, свой код ещё не нужен.
2. Сравнивайте одинаковый объём. Тариф платформы, порог проекта и месяц разработки покупают разную работу.
3. Принимайте повторы и сбои вместе с покупкой. У оплаты, заказа и отгрузки должны совпадать статусы.
4. Ограничьте первую версию завершённым сценарием. Следующие возможности получают отдельные задачи.
5. Назначьте владельца магазина после запуска. Сбой должен оставлять исправление и проверку следующего выпуска.