
Разработка веб-сервиса на заказ: этапы и сроки
Заказная разработка веб-сервиса — это проектирование и код под ваши процессы: от discovery до поддержки. Разбираем этапы, сроки и бюджет.
Разработка веб-сервиса на заказ
Заказной веб-сервис — это программный продукт, спроектированный под конкретные процессы компании: он считает, хранит, автоматизирует и продаёт, а не просто рассказывает о бизнесе.
В статье — как устроена разработка веб-сервиса на заказ: из каких этапов состоит процесс, сколько занимает времени, из чего складывается бюджет и какие ошибки чаще всего съедают срок и деньги. Материал рассчитан на заказчиков — владельцев бизнеса, продакт-менеджеров и руководителей, которые выбирают подрядчика и хотят понимать, что именно они покупают.
Что именно вы заказываете
Под «веб-сервисом» обычно понимают приложение, доступное через браузер и решающее прикладную задачу: личный кабинет клиента, систему бронирования, маркетплейс, CRM для отдела продаж, сервис расчётов, портал для партнёров, платёжную витрину. В отличие от сайта, у сервиса есть пользовательские роли, база данных, бизнес-логика, интеграции и админка.
Разработка на заказ означает, что продукт создаётся с нуля под ваш сценарий. Вы получаете исходный код и документацию, а не аренду чужой системы с фиксированным набором функций. Обратная сторона — ответственность за развитие продукта лежит на вас: его нужно проектировать, тестировать и поддерживать.
Информационный сайт и веб-сервис
Информационный сайт
Рассказывает о компании. Контент обновляют вручную, данные живут в разрозненных таблицах, а логика процессов — в головах сотрудников.
Веб-сервис
Считает, хранит и автоматизирует: роли, права, статусы, интеграции, отчёты — единый рабочий контур с данными в одной базе.
Стоит ли платить за уникальный код
Дальше разберём, в каких ситуациях кастомная разработка выигрывает у коробочного решения, а в каких превращается в неоправданные расходы.
Когда заказная разработка оправдана
Заказная разработка окупается, когда логика продукта — ваше конкурентное преимущество. Первый признак: процессы настолько специфичны, что под них нет готового софта, а доработки коробки упираются в ограничения платформы. Второй: вы планируете расти в разы и нуждаетесь в архитектуре, которая выдержит нагрузку, а не в тарифе с потолком по числу пользователей. Третий: сервис — точка контакта с клиентом, и скорость, интерфейс и сценарии должны быть вашими, а не шаблонными.
Если задача типовая — лендинг, интернет-магазин на 200 товаров, стандартный документооборот — разумнее начать с готового решения или конструктора. Кастом включают только на том узле, где вы действительно отличаетесь от конкурентов, а остальное закрывают проверенными продуктами.
Что получает бизнес
Заказной сервис редко покупают ради «современного дизайна» — его покупают ради измеримого эффекта: сокращения ручных операций, роста конверсии, возможности запустить продукт, который на готовой платформе просто не собрать.
Что даёт заказной веб-сервис
- 01
Автоматизация рутины: согласования, сверки, рассылки и расчёты выполняет система, а не сотрудник вручную
- 02
Собственная логика: сценарии описывают ваш процесс продаж или обслуживания, а не «как задумано в шаблоне»
- 03
Масштабирование: архитектура проектируется под рост нагрузки, новые города, каналы и тарифы
- 04
Интеграции: обмен данными с 1С, складом, платёжными провайдерами, CRM и внешними API в едином контуре
- 05
Владение активом: код, база и документация принадлежат компании, продукт можно развивать с любым подрядчиком
- 06
Управляемость: метрики, журналы событий и статусы помогают принимать решения по цифрам, а не по ощущениям
Как устроен процесс
Ниже — этапы, которые проходит почти любой заказной проект. Порядок принципиален: пропуск discovery или аналитики почти всегда возвращается переделками на этапе кода, когда изменения стоят в разы дороже.
Этапы разработки веб-сервиса
- 01
Discovery и аналитика (2–3 недели): интервью с командой, описание процессов, гипотез и метрик успеха, прототипы ключевых экранов.
- 02
Проектирование: архитектура, схема данных, роли и права доступа, перечень интеграций, техническое задание и оценка трудозатрат.
- 03
Дизайн и UX: кликабельный прототип, интерфейсные решения для каждой роли, проверка сценариев на реальных рабочих задачах.
- 04
Разработка MVP (8–16 недель): бэкенд, фронтенд, интеграции и админка — итерациями по две недели со сборкой на тестовом стенде.
- 05
Тестирование и приёмка: функциональные и нагрузочные проверки, проверка безопасности, исправление дефектов, приёмочные сценарии заказчика.
- 06
Запуск и поддержка: развёртывание в продуктивной среде, мониторинг, обучение сотрудников, план развития на следующие итерации.
Безопасность и требования закона
Отдельная строка расходов, которую часто забывают в смете, — соответствие требованиям. Если сервис обрабатывает персональные данные, он попадает под 152-ФЗ: нужно определить состав данных, оформить согласия, ограничить доступы по ролям и разместить базу на территории России.
Сколько это занимает
Сроки удобно планировать не по дате финального релиза, а по контрольным точкам. Так видно, где проект отстаёт, и можно вовремя сокращать объём, а не сдвигать запуск.
Первые 12 недель типового MVP
- 01–02
Discovery и аналитика
Интервью, карта процессов, гипотезы, метрики успеха, черновой прототип.
- 03–04
Проектирование и дизайн
Архитектура, схема данных, права ролей, интерфейсы ключевых экранов.
- 05–10
Разработка итерациями
Спринты по две недели, демо заказчику, сборка на тестовом стенде, интеграции.
- 11
Тестирование и приёмка
Функциональные и нагрузочные проверки, безопасность, приёмочные сценарии.
- 12
Запуск и обучение
Продуктивная среда, мониторинг, инструкции для сотрудников, план развития.
Стек и инфраструктура
Технологии выбирают не по моде, а по задаче, нагрузке и наличию специалистов на рынке. Для типового сервиса это чаще всего связка из реляционной базы, серверного фреймворка и современного фронтенда; при высоких нагрузках добавляют кеширование и очереди сообщений.
Инфраструктуру размещают в облаке. Для российской аудитории логичны Яндекс Облако, Selectel или VK Cloud; при работе с зарубежными рынками — Google Cloud или AWS. Аналитику ставят в паре Яндекс Метрика и Google Analytics, а техническое состояние отслеживают через Яндекс Вебмастер и Google Search Console.
| Компонент | Что выбирают чаще |
|---|---|
| База данных | PostgreSQL, MySQL |
| Серверная часть | Node.js, Python, PHP, Java |
| Клиентская часть | React, Vue, TypeScript |
| Инфраструктура | Яндекс Облако, Selectel, Google Cloud |
| Аналитика | Яндекс Метрика, Google Analytics |
| Приём платежей | ЮKassa, CloudPayments, Stripe |
| Уведомления | SMS-шлюз, email, push-сервис |
Ошибки, которые дороже всего
Даже при аккуратном процессе проект можно потерять на типовых решениях. Ниже — то, что чаще всего переносит сроки и раздувает бюджет именно в заказной разработке.
Ошибки при заказной разработке веб-сервиса
Как выглядит на практике
- ТЗ собрали за неделю «на словах», а на третьем спринте выяснилось, что половина процессов описана неверно
- Объём функций не ограничили: к MVP добавили ещё три модуля, и релиз сдвинулся на два месяца
- Подрядчика выбрали по минимальной ставке, а на поддержке оказалось, что документации нет и передать проект некому
Как делать правильно
- 01
Фиксировать требования письменно и проверять их прототипами до старта разработки
- 02
Жёстко ограничивать объём MVP, а остальные идеи складывать в бэклог следующих версий
- 03
Сравнивать подрядчиков по процессу, портфолио и прозрачности отчётов, а не только по цене
- 04
Заранее договариваться о передаче кода, документации и доступов при завершении проекта
Из чего складывается бюджет
Стоимость заказного веб-сервиса считают по трудозатратам команды, а не «по количеству экранов». В расчёт входят аналитика и проектирование, дизайн, разработка, тестирование, инфраструктура и поддержка. Две компании с одинаковым списком функций могут получить разные сметы — разница в интеграциях, требованиях к нагрузке и безопасности.
Сколько это занимает и стоит
На что смотреть при выборе
Сметы у разных исполнителей расходятся в разы, и дело не только в ставках. Дальше — признаки, по которым команда отличается от случайных подрядчиков, собравшихся под конкретный заказ.
Как выбрать исполнителя
Смотрите на процесс, а не на обещания. Хороший подрядчик до договора задаёт неудобные вопросы про процессы, данные и метрики, сам предлагает состав MVP и показывает, как будет отчитываться. Вам должны быть понятны три вещи: кто в команде отвечает за продукт, как выглядит демонстрация каждые две недели и что произойдёт, если проект придётся передать другой команде.
Проверьте портфолио на предмет похожих задач и попросите контакты заказчиков. Отдельно обсудите, кому принадлежат код и документация, как устроена поддержка после релиза и по какой ставке считаются доработки. Договор должен фиксировать этапы, результат каждого этапа и порядок приёмки — тогда спорные ситуации решаются по документу, а не по памяти.
Что происходит после запуска
Релиз — не финиш, а точка, с которой начинается работа с реальными данными. Первые месяцы уходят на мониторинг, исправление дефектов, обучение сотрудников и доработки по обратной связи. Бюджет поддержки планируют заранее: в среднем это 15–20% стоимости разработки в год, а при высокой нагрузке или строгих требованиях к безопасности — больше.
Заодно фиксируйте метрики: время выполнения операций, конверсию сценариев, число обращений в поддержку, стоимость обработки одного заказа. Именно они показывают, окупился ли сервис, и определяют, что делать в следующей версии.
Коротко о главном
- 01
Кастом оправдан там, где логика продукта отличается от типовой
- 02
Проект начинается с discovery и аналитики, а не с кода
- 03
MVP занимает в среднем 8–16 недель и требует жёсткого ограничения объёма
- 04
Передачу кода, документации и доступов закрепляют в договоре сразу
- 05
Поддержку и развитие планируют отдельной строкой бюджета заранее
Когда вы понимаете этапы, состав работ и критерии приёмки, разговор с подрядчиком переходит из плоскости «сколько это стоит» в плоскость «какой результат мы получаем на каждом шаге». Это и есть главный признак здорового проекта.
Часто задаваемые вопросы
Discovery и проектирование — 2–4 недели, разработка MVP — в среднем 8–16 недель. Срок зависит от числа ролей, интеграций и требований к нагрузке.
Смета считается по трудозатратам команды: аналитика, дизайн, разработка, тестирование, инфраструктура. Типовой внутренний сервис начинается от 1,5 млн ₽, платформы со сложной логикой — от 4–6 млн ₽.
Да, это стандартный подход. Первая версия закрывает один-два ключевых сценария, остальное уходит в бэклог. Главное — заложить архитектуру, которая выдержит следующие модули.
Заказчику, если это зафиксировано в договоре. Требуйте передачи исходного кода, документации и доступов — иначе сменить подрядчика будет сложно.
Да. Мониторинг, исправление дефектов и доработки по обратной связи требуют около 15–20% бюджета разработки в год.
Расскажите о задаче — соберём состав MVP и оценим сроки
За 30 минут разберём процессы, предложим состав первой версии и назовём вилку бюджета.
Спасибо за заявку!
Мы свяжемся с вами в ближайшее время.
Более 60 запущенных сервисов



