Веб-приложение разрабатывают в шесть этапов: разбор задачи и границ первой версии, прототип, дизайн, разработка итерациями, тестирование с запуском и пилот на реальных пользователях. По публичным страницам студий MVP занимает от одного до трёх месяцев, полноценная система от двух до шести. Стек состоит из интерфейса, серверной части с API, базы данных и инфраструктуры, а выбирать его стоит по задаче и по тому, кто будет поддерживать продукт. Бюджет считается как часы специалистов по этапам, умноженные на ставку.
Разработка веб-приложений идёт в шесть этапов: разбор задачи и границ первой версии, прототип, дизайн интерфейса, разработка, тестирование с запуском и пилот на реальных пользователях. По опубликованным страницам студий первая рабочая версия (MVP) занимает от одного до трёх месяцев, а полноценная система от двух до шести месяцев. Стек выбирают не по моде, а по задаче, по тому, кого вы сможете нанять для поддержки, и по требованиям к данным. Ниже этапы с результатом каждого, типовой стек, от чего зависят сроки и бюджет и как проверить готовность к старту.
Что такое веб-приложение и чем оно отличается от сайта
Веб-приложение это программа, которая работает в браузере: пользователь не читает страницы, а выполняет действия и работает с данными. Личный кабинет, CRM, портал для дилеров, сервис бронирования, внутренняя система учёта: всё это веб-приложения.
| Вид | Что делает пользователь | Где работает | Когда выбирать |
|---|---|---|---|
| Сайт | Читает, сравнивает, оставляет заявку | Браузер | Нужно привлечь клиента и рассказать об услуге |
| Веб-приложение | Входит под своей учётной записью, работает с данными, видит свою роль | Браузер на компьютере и телефоне | Нужен рабочий инструмент для клиентов или сотрудников |
| Прогрессивное веб-приложение (PWA) | То же, но может устанавливаться на устройство и работать частично без сети | Браузер, иконка на экране | Нужен опыт приложения без публикации в магазинах |
| Мобильное приложение | Работает с камерой, push, офлайн, датчиками | iOS и Android | Пользователи каждый день с телефона, важны функции устройства |
Про прогрессивные веб-приложения подробно написано в документации MDN: это веб-приложения, которые с помощью современных браузерных API ведут себя похоже на установленные программы. Если вы решаете, делать ли программу вообще или обойтись платформой, сначала посмотрите разбор платформа, конструктор или код.
Этапы разработки веб-приложения
Каждый этап разработки веб-приложения заканчивается конкретным результатом, который можно проверить. Если подрядчик не может назвать результат этапа, этап будет тянуться.
| Этап | Что происходит | Результат | Кто нужен от вас |
|---|---|---|---|
| Разбор и границы MVP | Для кого продукт, какие задачи решает, что войдёт в первую версию | Список функций первой версии и критерии успеха | Владелец продукта, который принимает решения |
| Прототип | Кликабельные экраны основных сценариев | Утверждённые сценарии | Будущие пользователи для проверки |
| Дизайн | Визуальный стиль, компоненты, адаптив под телефон | Макеты ключевых экранов и набор компонентов | Тот, кто утверждает внешний вид |
| Разработка | Серверная часть, API, интерфейс, интеграции, роли и права | Работающие части на тестовом стенде после каждой итерации | Регулярные короткие приёмки |
| Тестирование и запуск | Проверка сценариев, нагрузки, безопасности, перенос данных | Продукт на рабочем сервере, резервные копии, мониторинг | Данные для переноса, доступы к домену и сервисам |
| Пилот | Работа небольшой группы пользователей, сбор замечаний | Список доработок и решение о полном запуске | Группа пользователей и время на обратную связь |
Сколько времени занимает разработка
Срок разработки веб-приложения задают не строки кода, а число ролей, сценариев и интеграций. Публичных ориентиров у студий немного, но они есть.
- Студия Surf пишет на странице веб-разработки, что MVP стартует от одного месяца, небольшую систему собирают за один-два месяца, крупную за квартал.
- Студия Alto указывает классический вариант разработки веб-приложения от двух до шести месяцев, ускоренный от полутора до четырёх, а типичный срок запуска MVP от трёх месяцев.
Ниже пример, как может распределиться время на MVP личного кабинета с двумя ролями и одной интеграцией. Это иллюстрация порядка величин, а не норма.
Как читать: в сумме около 14 недель, что укладывается в публичные ориентиры студий для MVP. Дизайн может частично идти параллельно с началом разработки, а пилот уже работает на реальных пользователях. Каждая дополнительная роль, интеграция или согласование, которое ждёт ответа неделю, сдвигает срок. Вывод: самый длинный этап разработка, но сократить срок проще всего на первых двух, когда вы убираете лишнее из первой версии.
Сильнее всего сроки растягивают три вещи: решения, которые принимаются неделями, интеграции с системами без документации и функции, которые добавляются в первую версию по ходу работы. Защититься от этого помогают три правила: один человек со стороны заказчика принимает решения в течение пары дней, доступы к API внешних систем получают до начала разработки, а новые идеи записывают в список следующей версии, а не в текущую. Чем MVP отличается от прототипа и пилота, описано в статье что такое MVP.
Стек: из чего собирают веб-приложение
Веб-приложение состоит из четырёх частей: интерфейс в браузере, серверная часть с API, база данных и инфраструктура. Для каждой есть несколько распространённых вариантов, и почти любой из них подходит для бизнес-приложения. Если контент нужен сразу в нескольких местах, посмотрите статью headless CMS: что это.
| Слой | Распространённые варианты | По какому признаку выбирать |
|---|---|---|
| Интерфейс | React, Vue, Angular, серверная отрисовка страниц | Сложность экранов, опыт команды, кто будет поддерживать |
| Серверная часть | Node.js, Python, PHP, Go, Java, C# | Интеграции, нагрузка, рынок разработчиков для поддержки |
| База данных | PostgreSQL, MySQL, для отдельных задач Redis или поисковые движки | Структура данных, отчёты, объёмы |
| Инфраструктура | Облачный или свой сервер, контейнеры, резервные копии, мониторинг | Где должны лежать данные, требования безопасности, бюджет |
Главный критерий стека. Спросите себя, кого вы найдёте через два года, если текущий подрядчик уйдёт. Популярный стек с понятной документацией надёжнее редкого, даже если редкий чуть быстрее.
Из чего складывается бюджет
Бюджет веб-приложения считается как часы работы специалистов на каждом этапе, умноженные на ставку. Например, студия Alto публикует ставку 2 800 ₽ в час за работу разработчика и аналитика и пишет, что точная цена определяется после анализа требований. Других публичных ставок для сравнения вы найдёте немного: большинство студий называют цену после оценки.
- Аналитика и прототип. Дешёвый этап, который экономит больше всего денег.
- Дизайн. Зависит от числа уникальных экранов, а не от числа страниц.
- Разработка. Основная часть бюджета, растёт с каждой ролью и интеграцией.
- Тестирование и запуск. Часто недооценивают, хотя ошибки после запуска обходятся дороже.
- Поддержка. Сервер, обновления, исправления, мелкие доработки каждый месяц.
Как посчитать бюджет, срок и поддержку на конкретном примере перехода с таблиц, разобрано в статье веб-приложение вместо Excel: бюджет, срок и поддержка.
Безопасность и данные
Безопасность закладывают в первую версию, потому что права, вход и хранение данных тяжело переделывать в работающем продукте.
- Типовые уязвимости. Попросите подрядчика показать, как он закрывает риски из списка OWASP Top 10: это общепринятый перечень самых критичных рисков веб-приложений.
- Роли и права. Каждый пользователь видит только свои данные, действия пишутся в журнал.
- Персональные данные. Часть 5 статьи 18 закона 152-ФЗ требует, чтобы при сборе персональных данных граждан России запись, хранение и другие операции с ними велись с использованием баз данных на территории России. Подробнее о данных в проектах разобрано в статье классы данных и локализация.
- Резервные копии. Как часто делаются, где хранятся, проверено ли восстановление.
Что вы должны получить в конце проекта
В конце проекта у вас должен остаться не только работающий продукт, но и всё, что нужно, чтобы его развивать без исходной команды. Составьте этот список до договора и включите его в приёмку.
| Что передаётся | Зачем |
|---|---|
| Исходный код в репозитории компании | Любой новый разработчик начинает работу с него, а не с запроса к прежнему подрядчику |
| Описание архитектуры и схемы данных | Чтобы понимать, где что хранится и как связаны части системы |
| Описание API и интеграций | Чтобы подключать новые системы и мобильное приложение без раскопок |
| Инструкция по развёртыванию | Чтобы поднять копию на новом сервере за часы, а не за недели |
| Доступы к серверу, домену, почте и внешним сервисам | Чтобы владельцем инфраструктуры была компания |
| Порядок резервного копирования и проверенное восстановление | Чтобы сбой сервера не превратился в потерю данных |
| Список известных ограничений и отложенных функций | Чтобы следующая версия начиналась с понятного плана |
Приёмку первой версии лучше проводить на реальных сценариях, а не по списку экранов: пользователь проходит путь от входа до результата, а вы смотрите, где он застревает. Это занимает день, но показывает больше, чем недельное согласование макетов. Подробно о прототипе на примере сайта написано в статье прототип сайта: что это.
Готовы ли вы к старту
Разработка идёт быстрее, когда до первого созвона с подрядчиком у вас есть ответы на базовые вопросы. Пройдите чек-лист: он показывает, что ещё нужно решить.
Как понять, окупится ли первая версия
Если веб-приложение продаёт услугу клиентам, его окупаемость считают через воронку: сколько людей приходит, сколько регистрируется, сколько платит и сколько остаётся после расходов. Цифры для расчёта берите из похожего продукта, ручного пилота или лендинга с формой заявки, а не из оптимистичного плана. Для внутренних систем считают иначе, через сэкономленные часы и ошибки, как в статье про переход с Excel.
Как считается: регистрации = посетители × доля регистраций; новые платящие = регистрации × доля оплат; эффект в месяц = новые платящие × средняя первая оплата × маржа минус сервер и поддержка; трафик и привычка пользователей набираются за указанное число месяцев. Повторные оплаты постоянных клиентов калькулятор не учитывает, поэтому для подписочного сервиса результат осторожный. Конверсии берите из лендинга, ручного пилота или похожего продукта, а не из чужих отчётов.
Как выбрать подрядчика
Подрядчика выбирайте по тому, как он работает с неопределённостью, а не по портфолио картинок. Задайте эти вопросы на первой встрече.
- Что будет результатом первого этапа и сколько он стоит отдельно от разработки.
- Как часто вы будете видеть работающую версию на тестовом стенде.
- Кому принадлежат код, репозиторий, домен, сервер и аккаунты сервисов.
- Какая документация останется, если вы смените команду.
- Как устроены поддержка после запуска и реакция на ошибки.
- Что происходит, когда в середине работы вы хотите добавить функцию.
Если нужен исполнитель, который начнёт с границ первой версии и прототипа, посмотрите страницу разработка веб приложений на заказ: там описано, из чего состоит работа и что вы получаете на каждом шаге.
Частые ошибки
- Делать всё сразу. Первая версия с двадцатью функциями выходит позже и проверяет идею хуже, чем версия с пятью.
- Пропустить прототип. Изменение на макете стоит часы, то же изменение в готовом коде стоит дни.
- Оставить права на потом. Роли и доступы, добавленные в конце, ломают уже готовые экраны.
- Не договориться о владении. Код и сервер на аккаунте подрядчика превращают продукт в заложника.
- Не заложить поддержку. После запуска приложению нужны обновления, резервные копии и исправления каждый месяц.
- Alto: разработка веб-приложений, сроки этапов и ставка в час (проверено в октябре 2026)
- Surf: веб-разработка, сроки MVP и систем (проверено в октябре 2026)
- MDN Web Docs: прогрессивные веб-приложения
- OWASP Top 10: самые критичные риски безопасности веб-приложений
- Федеральный закон 152-ФЗ «О персональных данных», статья 18 (КонсультантПлюс)
Частые вопросы
Сколько времени занимает разработка веб-приложения?
По публичным страницам студий на октябрь 2026 MVP стартует от одного месяца у Surf и от трёх месяцев у Alto, полноценная разработка у Alto занимает от двух до шести месяцев. Срок зависит от числа ролей, сценариев и интеграций и от того, как быстро принимаются решения.
Чем веб-приложение отличается от сайта?
На сайте пользователь читает и оставляет заявку. В веб-приложении он входит под своей учётной записью, работает с данными и видит то, что положено его роли: кабинет клиента, CRM, портал дилера, сервис бронирования.
Какой стек выбрать для веб-приложения?
Для бизнес-приложения подходит почти любой распространённый стек: React или Vue в интерфейсе, Node.js, Python, PHP или Go на сервере, PostgreSQL или MySQL для данных. Важнее, чтобы под этот стек можно было найти разработчиков для поддержки и чтобы он подходил вашим интеграциям.
Что такое MVP и зачем он нужен?
MVP это первая рабочая версия продукта с минимальным набором функций, на которой проверяют идею на реальных пользователях. Он нужен, чтобы не тратить бюджет на функции, которые никому не понадобятся, и принимать решения о развитии по данным.
Можно ли потом сделать мобильное приложение на той же основе?
Да, если серверная часть с самого начала работает через API: тогда мобильное приложение подключается к тем же данным и логике. Ещё один вариант прогрессивное веб-приложение, которое устанавливается на телефон без публикации в магазинах.
Где хранить данные веб-приложения?
Если приложение собирает персональные данные граждан России, часть 5 статьи 18 закона 152-ФЗ требует вести их запись и хранение с использованием баз данных на территории России. Это стоит учесть при выборе сервера до начала разработки.
Кому должен принадлежать код веб-приложения?
Заказчику. Зафиксируйте в договоре передачу исходного кода, а репозиторий, сервер, домен и аккаунты внешних сервисов оформляйте на компанию с самого начала, чтобы смена подрядчика не останавливала продукт.
