Заказать разработку интернет-магазина: что входит, как проходит работа и как принять результат

Запрос «заказать разработку интернет-магазина» означает одно: человек уже решил строить магазин и ищет того, кому доверить работу. Не хочет читать туториалы и выбирать платформу самостоятельно. Хочет понять, как устроен процесс со стороны заказчика: что входит в работу, что нет, как проходят этапы, как принять результат и что происходит, если что-то пойдёт не так. Именно это я разберу ниже.
Большинство материалов на эту тему написаны студиями. Там красиво описан процесс с их стороны, но почти нет конкретики для клиента: какие документы, как принять работу, что считается багом, а что новым требованием. Эти дыры и закрываю.
Я fullstack-разработчик Евгений Волков, собираю интернет-магазины под ключ напрямую, без агентства. Через мои руки прошёл магазин ASYADROP: Nuxt 3, корзина на Pinia, эквайринг с автофискализацией по 54-ФЗ, доставка СДЭК с трекингом заказов. Работающий магазин с реальными заказами, не демо. Именно поэтому пишу про процесс конкретно, а не в общих словах.
Если вам нужны детали по ценам, это отдельная статья: сколько стоит интернет-магазин. Если думаете, на какой платформе строить: разбор платформ для интернет-магазина. Если хотите сначала разобраться во всём самостоятельно с нуля: подробный гайд как сделать интернет-магазин. Здесь только про то, как заказать и что получить на выходе.
Что входит в заказ, а что нет: честная таблица
Самый частый конфликт между клиентом и разработчиком возникает не из-за кода. Он возникает потому, что каждая сторона по-разному понимает слово «магазин под ключ». Один думает: «всё, открываю и торгую». Другой думает: «отдал работающую систему». Разбор ниже снимает это раз и навсегда.
| Блок | Входит по умолчанию | Не входит по умолчанию |
|---|---|---|
| Витрина | Каталог с категориями, фильтры, карточка товара, поиск | Тексты описаний и SEO-тексты категорий |
| Корзина и заказ | Корзина, оформление заказа, статусы | Скрипты обработки заказов (менеджеры, CRM) |
| Оплата | Подключение эквайринга, фискальный чек по 54-ФЗ | Сам договор эквайринга с банком (ваша сторона) |
| Доставка | Интеграция СДЭК / другой службы, выбор ПВЗ, трекинг | Настройка тарифов и зон доставки в личном кабинете |
| Администрирование | Панель управления товарами, заказами, промокодами | Наполнение каталога (загрузка товаров, фото) |
| Дизайн | Прототип, UI-дизайн, адаптив под мобильные | Фотосъёмка товаров, создание логотипа |
| Инфраструктура | Настройка сервера и деплой при запуске | Домен и хостинг (вы берёте их сами) |
| После запуска | Гарантийный период 30 дней | SEO-продвижение, контент-маркетинг, реклама |
Почему домен и хостинг не входят. Это ваши активы: вы владеете ими, и они должны быть зарегистрированы на вас, а не на подрядчика. Я помогу выбрать и настроить, но оплачиваете вы. Если разработчик хочет держать ваш домен на своём аккаунте, это красный флаг.
Наполнение каталога не входит потому, что это работа с вашим контентом, а не с кодом. Тысяча позиций с фото и описаниями это недели труда, которые стоят отдельно. Если поставщик отдаёт прайс в XML или CSV, я пишу импорт, и каталог загружается автоматически. Но сам прайс с контентом готовите вы.
Как проходит работа: этапы и точки контроля
Процесс разработки со стороны клиента часто выглядит как чёрный ящик: заплатил, подождал, получил. На деле у вас есть несколько чётких точек, где вы принимаете решение или даёте обратную связь. Это не бюрократия, это страховка от ситуации «сделали не то».
| Этап | Что делаю я | Что делает клиент | Срок фазы |
|---|---|---|---|
| Бриф и ТЗ | Задаю вопросы, готовлю техническое задание | Отвечаю на вопросы, согласовываю ТЗ | 2–5 дней |
| Прототип | Собираю структуру страниц, пользовательские пути | Принимаю прототип или прошу правки | 3–7 дней |
| Дизайн | Отрисовываю UI: главная, каталог, карточка, checkout | Принимаю дизайн, даю правки до 2 итераций | 1–2 недели |
| Разработка frontend | Верстаю и подключаю логику витрины | На связи для уточнений, готовлю контент | 2–4 недели |
| Backend и интеграции | Пишу API, подключаю оплату, доставку, админку | Передаю доступы к эквайрингу и сервисам доставки | 1–3 недели |
| Тестирование | Прогоняю сценарии, нахожу и чиню баги | Тестирую сам по чеклисту, фиксирую замечания | 3–7 дней |
| Запуск и сдача | Деплой на ваш сервер, финальная настройка | Принимаю работу, подписываю акт, вношу остаток | 2–3 дня |
Два момента, где клиенты чаще всего теряют время. Первый: задержка с передачей доступов. Нужен логин в личном кабинете банка для подключения эквайринга, данные аккаунта СДЭК. Чем раньше вы их передаёте, тем раньше готова интеграция. Второй: затянутое согласование дизайна. Два круга правок заложены в сроки, третий и последующие их сдвигают.
Дизайн я принимаю итерациями, а не в конце. Увидели прототип и поняли, что хотите другую структуру каталога, лучше сказать на этапе прототипа, а не после вёрстки. Переделать структуру навигации в HTML дороже, чем передвинуть блоки в Figma.
Оплата проходит в несколько этапов, а не одним платежом в конце. Обычная схема: предоплата 40–50% при подписании договора, промежуточный платёж после согласования дизайна, остаток после приёмки и подписания акта. Это страхует обе стороны: я не работаю бесплатно, вы не платите за то, чего ещё нет.
Техническое задание составляю я, а не вы. Это распространённое заблуждение: клиент думает, что должен прийти с готовым ТЗ на сотню страниц. Не должен. Ваша задача рассказать о бизнесе: что продаёте, как устроена логистика, какой каталог, кто целевой покупатель. ТЗ пишу я по итогам брифа. Вы его читаете и согласовываете. Если что-то описано неверно или чего-то не хватает, правим до подписания. Подписанное ТЗ это граница между тем, что входит в работу, и тем, что будет обсуждаться отдельно.
Приёмка: как принять готовый магазин
Это самый важный раздел, который студии и фрилансеры почти никогда не описывают. Приёмка это не «посмотрел, понравилось, подписал». Это конкретный набор проверок, которые подтверждают: магазин работает по всем сценариям, а не только по показательному.
Ниже чеклист. Пройдите его сами, на телефоне и на компьютере, до того как подписать акт.
| Сценарий | Что проверяете | Результат |
|---|---|---|
| Оформление заказа | Добавьте товар в корзину, пройдите checkout до конца | Заказ создан, письмо пришло вам и клиенту |
| Тестовая оплата | Оплатите реальной картой на минимальную сумму (10–100 ₽) | Платёж прошёл, фискальный чек по 54-ФЗ пришёл на email |
| Корзина после перезагрузки | Добавьте товары, обновите страницу | Корзина сохранила содержимое |
| Мобильная версия | Откройте магазин с телефона, оформите заказ | Всё читается, кнопки не уезжают за экран |
| Фильтры и поиск | Применяйте фильтры, ищите товары | Результаты меняются без ошибок |
| Скорость | Проверьте через PageSpeed Insights | LCP менее 3 секунд на мобильном |
| Отмена и пустые состояния | Удалите товар из корзины, найдите несуществующий товар | Корзина обновилась, 404 корректный |
| Выгрузка данных | Убедитесь, что заказы видны в админке | Данные сохраняются и доступны |
| Промокод (если есть) | Примените промокод при оформлении | Скидка посчиталась верно, итог правильный |
Если что-то из этого ломается при приёмке, это исправляется до подписания акта. Письменно фиксируете замечание, я исправляю и передаю на повторную проверку. Только после того как все пункты пройдены, подписывается акт и вносится финальный платёж.
Почему тестовая оплата реальной картой обязательна. Тестовые режимы эквайринга работают иначе, чем боевые. Я видел ситуации, когда в тестовом режиме всё проходит, а в боевом банк отклоняет платёж из-за мелкой ошибки в параметрах запроса. Лучше поймать это на приёмке за 100 ₽, а не потерять реальные заказы на следующий день после запуска.
Отдельно про мобильную версию. Многие проверяют магазин только с компьютера, потому что так удобнее смотреть детали. Это ошибка. Больше половины покупателей в 2026 году приходят с телефона, и если кнопка «Оформить заказ» уезжает за экран или форма доставки не помещается на маленьком дисплее, вы теряете половину продаж молча, без единой жалобы. Поэтому приёмку на мобильном я считаю обязательной, а не опциональной.
Ещё один сценарий, который часто пропускают: граничные состояния. Что происходит, если товар закончился прямо в момент оформления. Что видит покупатель, если оплата отклонена банком. Приходит ли уведомление о новом заказе продавцу. Сломанный пустой каталог при нулевом результате поиска. Всё это тоже входит в приёмку. Эти сценарии редко ломаются с красным экраном ошибки, они чаще дают белую страницу или зависший спиннер, и клиент уходит, ничего не написав.
Гарантия и поддержка после запуска
Гарантия без механики, это просто слово. Вот конкретика.
Гарантийный период составляет 30 дней с момента подписания акта. В этот период баги исправляются бесплатно и в приоритетном порядке, срок исправления 1–3 рабочих дня в зависимости от сложности.
Что считается гарантийным случаем: ошибка, которая воспроизводится в браузере и которой не было при приёмке, при условии что с вашей стороны ничего не менялось. Упал checkout при определённом сочетании параметров заказа, не отправляется письмо на конкретный почтовый домен, сломался фильтр после добавления нового товара, это гарантия.
Что не является гарантийным случаем: изменение требований после запуска, обновление внешних сервисов (эквайринг поменял API на своей стороне), действия с хостингом или сайтом на вашей стороне, новый функционал, который не был в ТЗ.
Почему граница «ваша сторона / моя сторона» важна. Один реальный пример: клиент обновил PHP на хостинге до несовместимой версии, и часть функций сломалась. Это не баг в коде, это последствие действий на хостинге. Другой пример: поставщик эквайринга без предупреждения поменял формат callback-уведомлений. Это внешнее изменение. В таких случаях я помогаю починить, но уже не бесплатно, а по часовой ставке, потому что причина вне кода, который сдавался. Именно поэтому всё это фиксируется в договоре до старта, а не выясняется в момент конфликта.
Как оформить обращение: письменно (Telegram, email), с описанием сценария воспроизведения. «Что-то не работает» не помогает. «Оформляю заказ, выбираю СДЭК, нажимаю "Оплатить", белый экран» помогает. Чем точнее описание, тем быстрее исправление.
После гарантийного периода поддержка возможна по договорённости: часовая или ежемесячная, в зависимости от объёма задач. Большинство клиентов выбирают формат «по необходимости»: написали, назвали задачу, получили оценку времени, подтвердили. Без обязательной ежемесячной платы, если задач нет.
Заказать у студии или у solo-fullstack
Разберу честно, без маркетинга.
+Плюсы
- Один ответственный: я и проектирую, и верстаю, и пишу backend, и разворачиваю сервер. Нет ситуации «это вопрос к другому отделу».
- Прямой контакт без аккаунт-менеджера: вы пишете мне и получаете ответ от разработчика, а не от менеджера, который передаст вопрос.
- Без аутсорса без вашего согласования: студии часто отдают frontend одному подрядчику, backend другому. У меня стек полностью под моим контролем.
- Ниже цена при том же стеке: вы платите за разработку, не за структуру агентства (офис, менеджеры, продажники).
- Проще согласовать правки: изменение в логике не ждёт очереди в тикет-системе, я слышу задачу и делаю.
−Минусы
- Нет команды на параллельную работу: если задача предполагает одновременно дизайн, разработку и SEO, это последовательно, а не параллельно.
- Ограничен по пропускной способности: одновременно веду 1–2 проекта. Если начать нужно прямо сейчас, а слот занят, придётся подождать или искать студию.
- Нет готовой инфраструктуры поддержки 24/7: ночной сбой с немедленным откликом требует дополнительного договора.
Страх «solo-разработчик исчезнет» понятен. Мой ответ на него: весь код в вашем репозитории с первого дня (Git), все доступы передаются вам на приёмке. Домен, хостинг, аккаунт эквайринга зарегистрированы на вас, а не на меня. Если через год вы найдёте другого разработчика, он прочитает код и продолжит. Закрытого чёрного ящика нет.
Есть сценарии, когда студия объективно лучше. Если вам нужно параллельно работать над дизайном, разработкой и SEO одновременно, у большой команды это получится быстрее. Если проект требует нескольких разработчиков одновременно (большая enterprise-система с десятками интеграций), solo-ресурс это узкое горло. Если вам важна круглосуточная поддержка с SLA в час, это требует дежурной смены, которой у меня нет. В таких случаях честнее сразу идти в агентство.
Для большинства магазинов малого и среднего бизнеса ни параллельная команда, ни ночная дежурная смена не нужны. Нужен рабочий магазин без лишних посредников и по адекватной цене. Для этого solo-формат работает лучше.
Про критерии выбора подрядчика в целом, с чеклистом и красными флагами, я разобрал в отдельной статье: как выбрать подрядчика для разработки сайта.
Сколько стоит и сколько занимает
Коротко, потому что детальная смета это отдельный материал.
Магазин средней сложности с витриной, корзиной, оплатой и интеграцией доставки у меня стоит от 80 000 ₽. Срок 6–10 недель. Чем больше уникальной логики (механика дропов, программа лояльности, связка с 1С), тем выше и то, и другое.
Чтобы не гадать, нужен бриф. После 15-минутного разговора или письма с описанием задачи я называю вилку. Расчёт без брифа это цифра с потолка, а не смета.
Детальные вилки по типам магазинов, смету по этапам и скрытые расходы разложил в статье сколько стоит интернет-магазин. А если ещё не решили, какой стек подходит под ваши задачи: на чём собрать интернет-магазин.
Как заказать: что подготовить
Чем лучше вы подготовились до первого разговора, тем точнее смета и тем быстрее старт. Не нужно готовить дизайн или техническое задание самостоятельно, этим занимаюсь я. Но несколько вещей сильно ускоряют процесс.
Опишите тематику и каталог. Что продаёте, сколько товаров сейчас и какой рост ожидаете через год. Сто позиций и десять тысяч это разные решения по архитектуре и стеку. Если есть прайс поставщика в Excel или XML, сразу скажите: импорт данных это отдельная задача, и её лучше заложить в ТЗ, а не вспоминать в конце.
Соберите референсы. Два-три магазина, которые вам нравятся по структуре или ощущению. Не обязательно из вашей ниши. Достаточно сказать «хочу, чтобы checkout был как здесь, а карточка товара как вот тут». Это сразу снимает половину неопределённости и экономит несколько итераций обсуждения дизайна.
Определитесь с интеграциями. Какой эквайринг планируете (ЮKassa, Сбер, Точка), какая служба доставки (СДЭК, Почта, Boxberry), нужна ли двусторонняя связка с 1С, нужны ли автоматические выгрузки на Ozon или Wildberries. Это самый весомый фактор в оценке сроков и стоимости. Магазин без интеграций и магазин с полноценным обменом с 1С и тремя службами доставки это совершенно разные объёмы работы.
Подготовьте реквизиты для договора. Я работаю официально как ИП, договор и закрывающие документы (акт, счёт) входят в работу по умолчанию. Физическое лицо или ИП/ООО со стороны клиента, неважно, договор оформляется в обоих случаях. Для юридических лиц нужны реквизиты организации, для физлиц паспортные данные.
Загляните на страницу услуги. Там зафиксированы состав работ, сроки и условия: разработка интернет-магазина под ключ. Это удобнее, чем пересказывать устно.
Если хочется сначала самому разобраться в нюансах: что делают конструкторы, где их потолок и когда нужен кастом, всё это в статье как сделать интернет-магазин.
Один практический момент напоследок. Часто спрашивают: «Можно ли начать без ТЗ, просто поговорить?». Да, можно. Первый разговор это не обязательство. Рассказываете задачу, я прикидываю объём и называю вилку. Если вилка устраивает, двигаемся к брифу и ТЗ. Если не устраивает, расходимся без потерь времени с обеих сторон. Мне не выгодно брать проект, который не подходит по бюджету или требованиям: лучше честно сказать на старте, чем тянуть и разочаровать в середине.
Готовы обсуждать задачу? Пишите напрямую через форму на сайте или в Telegram. Опишите: что продаёте, примерный каталог, нужные интеграции. Я отвечу с уточняющими вопросами и сметой, без «купите сначала брифинг».


