Разработка веб-приложения 2026: как дойти до релиза без переделки на полпути

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

как устроена разработка веб-приложения: шесть этапов от идеи до релиза

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

Первый этап — техническое задание. Не общее «хотим удобный личный кабинет», а список сценариев с цифрами: сколько заявок в день оформляет отдел продаж, сколько складов подключено, кто видит какие данные и в каком статусе. Второй этап — архитектура: выбор базы данных, схема интеграции с учётными системами, план на рост нагрузки при открытии новых точек. Третий — сама разработка, обычно спринтами по одной-две недели с демо для заказчика после каждого спринта. Четвёртый — тестирование, включая нагрузочное: приложение должно держать пиковую нагрузку в пятницу вечером, когда склад закрывает отгрузки на выходные, а не только пять тестовых пользователей на ноутбуке разработчика. Пятый этап — релиз с планом отката на случай, если что-то сломается в проде в первый же день. Шестой — сопровождение: без него приложение начинает разваливаться при первом же обновлении 1С или смене API у логистического партнёра.

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

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

почему возникает разрыв между техническим заданием и готовым приложением

В логистической компании в Москве менеджер по продажам полтора месяца после релиза продолжал присылать клиентам скриншоты из 1С, хотя портал для отслеживания заявок уже работал. Формально проект был закрыт: техническое задание подписано, функциональность сдана, акт согласован с бухгалтерией. Но портал показывал статус заявки без привязки к реальному складскому остатку, потому что на встречах по постановке задачи сидели только IT-директор и разработчик — отдел продаж туда не звали.

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

Ставка здесь не абстрактная. Пока портал показывал неверный статус, отдел продаж вручную сверял данные по каждой заявке в мессенджере с кладовщиком — это часы каждую неделю, которые не попадают в смету проекта, но съедают всю его экономическую выгоду. А клиенты, которым присылали скриншоты вместо ссылки на портал, справедливо спрашивали, зачем компания вообще внедряла новую систему.

как исправить архитектуру, если приложение не тянет данные из 1С

Та же компания получила вторую проблему через три месяца после релиза. После планового обновления конфигурации 1С обмен данными с порталом перестал работать ночью, а склад узнавал об этом только утром — заявки зависали в статусе «в обработке», и менеджеры вручную звонили на склад уточнять остатки. Причина в том, что интеграцию на старте сделали через прямой запрос к базе 1С в обход штатного API — так было быстрее запустить проект в срок.

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

три сигнала, что интеграцию пора пересобирать

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

Рабочий вариант — отдельный слой интеграции: веб-приложение общается не напрямую с базой 1С, а через API или сервис обмена, который переживает обновления конфигурации и логирует каждый сбой отдельно от основного приложения, не роняя интерфейс для пользователей. Для B2B-сценариев, где приложением одновременно пользуются несколько отделов и данные обязаны совпадать с 1С без ручной сверки, дешевле закладывать такую интеграцию сразу — этим мы занимаемся в интеграции приложения с 1С.

что делать, если релиз откладывается снова и снова

Релиз веб-приложения для отдела логистики в одной подмосковной компании переносился четыре раза за полгода. Каждый перенос обосновывался разумно: «добавим ещё один отчёт», «поменяем логику согласования заявок», «нужна выгрузка в Excel для бухгалтерии». По отдельности любой запрос выглядел мелким. Но вместе они превратили проект с фиксированным техническим заданием в список хотелок без даты окончания.

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

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

как предотвратить срыв бюджета и сроков на следующем проекте

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

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

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

Разработка такого приложения начинается от 500 000 рублей, точная сумма зависит от количества сценариев и объёма интеграции с 1С; актуальные форматы работы и тарифы — на странице цен.

❓ Частые вопросы

Сколько времени занимает разработка веб-приложения для бизнеса?

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

Нужна ли интеграция с 1С, если веб-приложение будет работать отдельно от учётной системы?

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

Чем веб-приложение отличается от мобильного, если бизнесу нужно и то, и другое?

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

Сколько стоит разработка веб-приложения с интеграцией 1С?

Разработка начинается от 500 000 рублей, точная сумма зависит от количества сценариев, ролей пользователей и объёма интеграции с 1С. Актуальные форматы работы и тарифы — на странице цен ukved.ru.

Что делать, если разработку уже начали, а сроки постоянно срываются?

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