Изометрический чертёж песочных часов — из горловины падает изумрудный шарик, слева стопка жетонов

Разработка веб-сервиса на заказ: этапы и сроки

Заказная разработка веб-сервиса — это проектирование и код под ваши процессы: от discovery до поддержки. Разбираем этапы, сроки и бюджет.

Разработка веб-сервиса на заказ

Заказной веб-сервис — это программный продукт, спроектированный под конкретные процессы компании: он считает, хранит, автоматизирует и продаёт, а не просто рассказывает о бизнесе.

Готовый софт подстраивает вас под себя. Заказной сервис подстраивается под вас.

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

Что именно вы заказываете

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

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

сравнение

Информационный сайт и веб-сервис

01

Информационный сайт

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

02

Веб-сервис

Считает, хранит и автоматизирует: роли, права, статусы, интеграции, отчёты — единый рабочий контур с данными в одной базе.

чем сложнее процесс, тем выше эффект от перехода к сервису

Стоит ли платить за уникальный код

Дальше разберём, в каких ситуациях кастомная разработка выигрывает у коробочного решения, а в каких превращается в неоправданные расходы.

Когда заказная разработка оправдана

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

Если задача типовая — лендинг, интернет-магазин на 200 товаров, стандартный документооборот — разумнее начать с готового решения или конструктора. Кастом включают только на том узле, где вы действительно отличаетесь от конкурентов, а остальное закрывают проверенными продуктами.

Что получает бизнес

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

Что даёт заказной веб-сервис

  1. 01

    Автоматизация рутины: согласования, сверки, рассылки и расчёты выполняет система, а не сотрудник вручную

  2. 02

    Собственная логика: сценарии описывают ваш процесс продаж или обслуживания, а не «как задумано в шаблоне»

  3. 03

    Масштабирование: архитектура проектируется под рост нагрузки, новые города, каналы и тарифы

  4. 04

    Интеграции: обмен данными с 1С, складом, платёжными провайдерами, CRM и внешними API в едином контуре

  5. 05

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

  6. 06

    Управляемость: метрики, журналы событий и статусы помогают принимать решения по цифрам, а не по ощущениям

Как устроен процесс

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

Этапы разработки веб-сервиса

  1. 01

    Discovery и аналитика (2–3 недели): интервью с командой, описание процессов, гипотез и метрик успеха, прототипы ключевых экранов.

  2. 02

    Проектирование: архитектура, схема данных, роли и права доступа, перечень интеграций, техническое задание и оценка трудозатрат.

  3. 03

    Дизайн и UX: кликабельный прототип, интерфейсные решения для каждой роли, проверка сценариев на реальных рабочих задачах.

  4. 04

    Разработка MVP (8–16 недель): бэкенд, фронтенд, интеграции и админка — итерациями по две недели со сборкой на тестовом стенде.

  5. 05

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

  6. 06

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

Безопасность и требования закона

Отдельная строка расходов, которую часто забывают в смете, — соответствие требованиям. Если сервис обрабатывает персональные данные, он попадает под 152-ФЗ: нужно определить состав данных, оформить согласия, ограничить доступы по ролям и разместить базу на территории России.

Практика: требования к защите закладывают в архитектуру на этапе проектирования. Добавление шифрования, журналирования и разграничения прав после релиза обходится дороже и почти всегда сопровождается переработкой готовых модулей.

Сколько это занимает

Сроки удобно планировать не по дате финального релиза, а по контрольным точкам. Так видно, где проект отстаёт, и можно вовремя сокращать объём, а не сдвигать запуск.

таймлайн

Первые 12 недель типового MVP

  1. 01–02

    Discovery и аналитика

    Интервью, карта процессов, гипотезы, метрики успеха, черновой прототип.

  2. 03–04

    Проектирование и дизайн

    Архитектура, схема данных, права ролей, интерфейсы ключевых экранов.

  3. 05–10

    Разработка итерациями

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

  4. 11

    Тестирование и приёмка

    Функциональные и нагрузочные проверки, безопасность, приёмочные сценарии.

  5. 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 добавили ещё три модуля, и релиз сдвинулся на два месяца
  • Подрядчика выбрали по минимальной ставке, а на поддержке оказалось, что документации нет и передать проект некому

Как делать правильно

  1. 01

    Фиксировать требования письменно и проверять их прототипами до старта разработки

  2. 02

    Жёстко ограничивать объём MVP, а остальные идеи складывать в бэклог следующих версий

  3. 03

    Сравнивать подрядчиков по процессу, портфолио и прозрачности отчётов, а не только по цене

  4. 04

    Заранее договариваться о передаче кода, документации и доступов при завершении проекта

Из чего складывается бюджет

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

ориентиры

Сколько это занимает и стоит

2–3
недели
discovery и аналитика — до первой строки кода
8–16
недель
разработка MVP и вывод в продуктив
от 1,5 млн
рублей
типовой внутренний сервис с интеграциями
15–20%
в год
поддержка и развитие от стоимости разработки
цифры зависят от числа ролей, интеграций и требований к нагрузке

На что смотреть при выборе

Сметы у разных исполнителей расходятся в разы, и дело не только в ставках. Дальше — признаки, по которым команда отличается от случайных подрядчиков, собравшихся под конкретный заказ.

Как выбрать исполнителя

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

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

Что происходит после запуска

Релиз — не финиш, а точка, с которой начинается работа с реальными данными. Первые месяцы уходят на мониторинг, исправление дефектов, обучение сотрудников и доработки по обратной связи. Бюджет поддержки планируют заранее: в среднем это 15–20% стоимости разработки в год, а при высокой нагрузке или строгих требованиях к безопасности — больше.

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

Коротко о главном

Веб-сервис на заказ — это инвестиция в собственный цифровой актив, а не покупка готового продукта.
  1. 01

    Кастом оправдан там, где логика продукта отличается от типовой

  2. 02

    Проект начинается с discovery и аналитики, а не с кода

  3. 03

    MVP занимает в среднем 8–16 недель и требует жёсткого ограничения объёма

  4. 04

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

  5. 05

    Поддержку и развитие планируют отдельной строкой бюджета заранее

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

Часто задаваемые вопросы

Расскажите о задаче — соберём состав MVP и оценим сроки

За 30 минут разберём процессы, предложим состав первой версии и назовём вилку бюджета.

Бесплатная оценкаMVP за 8 недельБез навязчивых звонков

Более 60 запущенных сервисов

Политика конфиденциальности

При оставлении заявки на ресурсе «https://gurucontext.ru» пользователи предоставляют следующие сведения:

  • Имя
  • Контактный телефон или Telegram
  • Адрес сайта пользователя (не обязательно)

Также администрация сайта получает данные об IP-адресе посетителей, типе браузера, времени нахождения на сайте и прочие подобные сведения через сервисы статистики.

Использование информации

Вся полученная информация используется администрацией «https://gurucontext.ru» исключительно в целях связи с клиентом.

Защита персональных данных

Компания «https://gurucontext.ru» обязуется не разглашать сведения, полученные от пользователей, и хранит их в защищённом виде.

Предоставление данных третьим лицам

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

Контакты

Телефон: +7 (499) 955-47-00.
E-mail: info@gurucontext.ru.