Веб-приложение — программа, которая работает через браузер на любом устройстве с интернетом, без установки. Разработка минимального проекта занимает от 2 месяцев, среднего — от 4, продвинутого с кастомной логикой — от 5.
Начинать стоит с MVP: ключевой функционал, проверка гипотезы, и только потом расширение на основе реальной обратной связи, а не предположений на старте.
Какие бывают веб-приложения
Три типа, и выбор определяет остальную архитектуру проекта.
Многостраничное. Классический тип — несколько связанных страниц. Подходит для сложной функциональности: интернет-магазины, многофункциональные платформы, где много информации и разделов.
Одностраничное (SPA). Загружается один раз, дальше обновляется динамически без перезагрузки. Подходит для рабочих инструментов, где человек проводит много времени и много кликает: личные кабинеты, панели управления, интерфейсы операторов.
Прогрессивное (PWA). Сочетает сайт и мобильное приложение: работает офлайн, поддерживает push-уведомления. Хороший вариант, когда нужна мобильная логика без разработки отдельного приложения под iOS и Android. Мы подключаем PWA по умолчанию ко всем интерфейсам, которые делаем, — порталам, кабинетам, базам знаний, а иногда и к обычным сайтам.
| Тип | Для каких задач | Примерный срок | Наши проекты |
|---|---|---|---|
| Многостраничное | Платформы с большим числом разделов, интеграциями и ролями пользователей | от 4 месяцев | Корпоративный портал для фармацевтической группы (5 000+ активных пользователей); платформа поиска работы и сотрудников (50 млн+ анкет, отклик страницы до 40 мс) |
| Одностраничное (SPA) | Сфокусированные рабочие места: кабинет, панель управления, оператор | от 2 месяцев | Консоль диспетчеров для энергокомпании: заявки, бригады и аварийные участки на одной карте с обновлением в реальном времени; личные кабинеты партнёров с заказами и документами |
| Прогрессивное (PWA) | Мобильная логика без отдельного приложения: офлайн, уведомления | от 3 месяцев | Подключаем по умолчанию ко всем нашим интерфейсам. Например, портал и база знаний фармацевтической группы ставятся на телефон как приложение, открываются при слабом интернете и присылают уведомления о задачах и согласованиях |
Почему веб, а не десктопное приложение
Три практические причины, не общие слова про «удобство».
Веб-приложение доступно с любого устройства, где есть браузер — компьютер, смартфон, планшет. Десктопное решение требует установки на каждое конкретное устройство.
Обновления в вебе доходят до всех пользователей мгновенно — не нужно, чтобы каждый скачал новую версию. В десктопном мире это отдельная головная боль: часть пользователей годами сидит на устаревшей версии.
И по деньгам: веб-приложение обычно дешевле в реализации за счёт более простой архитектуры компонентов по сравнению с традиционным десктопным решением.
С чего начинается разработка: MVP и сбор требований
Прежде чем писать код, требования уточняют через CustDev-интервью с будущими пользователями. Цель — узнать, какие функции реально востребованы, как устроен путь клиента, и на что не стоит тратить ресурсы вообще.
Это разворот, который экономит бюджет: не «давайте сделаем всё, что придумали на планёрке», а «давайте узнаем, что реально нужно людям, которые будут этим пользоваться».
Дальше — MVP. В него входит ключевой функционал для получения бизнес-эффекта, а не всё сразу. Задача MVP — протестировать механику работы и собрать обратную связь. На основе этой обратной связи приложение дорабатывают и финализируют продуктовую стратегию.
Хороший пример — когда будущих пользователей подключают не на приёмке, а в проектирование процессов.
Кейс: портал, процессы которого формировали вместе с пользователями
Контекст. Дочерняя компания крупной фармацевтической группы: много подразделений, сложные кадровые и коммуникационные процессы. Запрос клиента звучал так: «Сложное, сделать простым и удобным».
Что сделали. Веб-портал с процессами, настраиваемыми под структуру компании: единое рабочее пространство, база знаний, кадровый контур с интеграциями в рекрутинговые площадки и учётные системы, мессенджеры для уведомлений. Процессы проектировали вместе с будущими пользователями: 250+ человек участвовали в формировании процессов и работали с нами на всех этапах. Стек: Go, SvelteKit, Temporal.
Итог. 6 месяцев, бюджет 8,9 млн ₽. 5 000+ активных пользователей, 1 000+ статей в базе знаний, 10+ интеграций с кадровыми системами.
Сколько по времени и от чего зависит сложность
Три уровня сложности — по срокам и составу функций.
| Уровень | Срок | Что входит |
|---|---|---|
| Минимальный | от 2 месяцев | Адаптивность, навигация между разделами, административная панель |
| Средний | от 4 месяцев | Прототип и функциональные требования, базовые анимации, управление данными через бэкенд |
| Продвинутый | от 5 месяцев | Всё из минимального и среднего плюс кастомные анимации, функционал под B2B/B2C, поиск по данным |
Теперь деньги. Считаем от ставки 3 500 ₽ за час, итог — вилка плюс-минус 20%:
| Уровень | Что входит | Часов | Бюджет |
|---|---|---|---|
| Минимальный | MVP: ядро функций, адаптивный интерфейс | около 750 | 2,1–3,2 млн ₽ |
| Средний | Управление проектами, HRM или CRM | 1 250–1 600 | 3,5–6,7 млн ₽ |
| Продвинутый | Складская система, B2B-портал, ERP | 2 500–4 700 | 7–20 млн ₽ |
Что меняет цифру:
- Интеграция со сторонней системой — около 30–50 часов на каждую.
- Мобильная часть: адаптивный интерфейс, PWA с офлайн-режимом и push-уведомлениями или нативные приложения.
- Безопасность: работа с персональными данными (152-ФЗ), требования ФСТЭК, частные требования заказчика.
1С, CRM, банк, ЭДО, телефония, маркетплейсы — каждая +40 часов
Ориентир бюджета
6,0–9,1 млн ₽
Фактическая стоимость, сроки и состав команды утверждаются с заказчиком индивидуально.
Это ориентир, а не смета. Точную цифру называем после разбора задачи: Получить расчёт.
Как проходит разработка: пять этапов
1. Анализ. Изучение потребностей заказчика, анализ рынка и конкурентов — какие функции реально будут востребованы.
2. Проектирование. Дизайн, архитектура, прототип, техническая спецификация с описанием функций.
3. Разработка. Написание кода на выбранном стеке.
4. Тестирование. Функциональное, нагрузочное, тестирование производительности. Найденные ошибки уходят обратно в разработку.
5. Запуск. Размещение на хостинге, передача документации по управлению и поддержке приложения.
Работа внутри этапов обычно строится спринтами по методологии Agile и Scrum: приоритеты корректируются по ходу, ориентируясь на заказчика, а не по жёсткому плану, зафиксированному в начале. Это экономит деньги и время на согласование изменений — правки не превращаются в отдельный проект с новым договором.
На чём строим, по слоям:
| Слой | Что берём | Зачем |
|---|---|---|
| Серверная часть | Go, Connect RPC для API | Один исполняемый файл, предсказуемое поведение под нагрузкой, простая эксплуатация |
| База данных | PostgreSQL, ClickHouse для аналитики | PostgreSQL — надёжная основа для транзакций. ClickHouse подключаем там, где нужна быстрая аналитика по большим объёмам |
| Долгие процессы | Temporal | Многошаговые процессы с повторами и компенсациями не теряются при сбоях |
| Интерфейс | Svelte 5, SvelteKit 2, Tailwind 4 | Лёгкий клиентский код и быстрая загрузка |
| Инфраструктура | Docker, Docker Swarm или Kubernetes, Ansible, Traefik | Окружение описано кодом и разворачивается одинаково на тесте и на проде |
Берём актуальные версии: Svelte 5, SvelteKit 2, Tailwind 4. Не тащим в новый проект то, что уже уходит с рынка.
Поддержка после запуска
После запуска работа не заканчивается. В поддержку входят консультации по вопросам эксплуатации, исправление ошибок и документация, которая позволяет заказчику самостоятельно управлять приложением.
Отдельно стоит фиксировать SLA — не формальность, а конкретные обязательства: время отклика на обращение, время восстановления после сбоя, процент доступности сервиса. Без этих цифр «поддержка» превращается в обещание на словах, которое нечем проверить.
SLA с отдельными условиями — платная услуга: её объём и стоимость обсуждаются отдельно и оформляются отдельным договором.
Начните с одного вопроса: какой тип веб-приложения закрывает вашу задачу — многостраничное, SPA или PWA. От этого ответа зависит и срок, и бюджет, и команда, которая понадобится.
Не начинаем с кода. Начинаем с того, как должен работать бизнес.
Опишите задачу: кто будет пользоваться приложением и что оно должно делать в первую очередь. Предложим тип приложения и состав MVP, назовём предварительные сроки и формат работы.
Первый разговор ни к чему не обязывает: после него будет понятно, нужна ли вам заказная разработка и в каком объёме.
Подробнее про подход к минимальной версии — в статье про разработку MVP. Общие ценовые вилки по типам продуктов — в материале про заказную разработку ПО.