Разработка веб-приложения на заказ: этапы, стек, сроки и цена
Заказчики, которые приходят ко мне с запросом на разработку веб-приложения, обычно уже прошли один круг. Они понимают, что им нужна не просто страничка, а рабочий инструмент: личный кабинет, где клиенты делают что-то полезное, автоматизация, которая снимает ручную работу, или сервис, который продают по подписке. Вопрос теперь другой: с кем строить, сколько это стоит и как не потерять полгода на проект, который в итоге не взлетит.
Меня зовут Евгений Волков, я fullstack-разработчик. Разработка веб-приложений на заказ это моя основная работа. Здесь разберу честно: когда реально нужна кастомная разработка, какой стек и почему, этапы с реальными сроками, ценовые вилки без студийной наценки и как выбрать исполнителя. Без шаблонных «гибкий подход» и «работаем по SCRUM». Только то, что я реально делаю на проектах.
Когда заказывают разработку веб-приложения
Не каждая бизнес-задача требует кастомного приложения. Начну с честного разграничения, потому что предложить разработку там, где хватит конструктора, мне невыгодно ни с точки зрения времени, ни репутации.
Личный кабинет и SaaS-сервис
Самая частая причина. Компания хочет, чтобы клиенты самостоятельно управляли заказами, видели историю, выставляли счета или загружали документы. Это уже не сайт, это приложение со своей логикой, аккаунтами и данными каждого пользователя.
SaaS (software as a service) идёт следующим уровнем: вы продаёте доступ к сервису по подписке. Биллинг, тарифные планы, аналитика использования, многоарендная архитектура. Построить такое на Tilda или WordPress не получится от слова совсем. Сколько стоит собрать SaaS с нуля и с чего начать фаундеру, я разобрал отдельно.
Автоматизация внутренних процессов
CRM, которая не похожа на стандартные Bitrix или amoCRM. Инструмент для менеджеров с уникальными полями, своими статусами и интеграцией с внутренними системами. Автоматизация документооборота. Дашборд, который собирает данные из трёх разных источников и показывает нужный срез.
Готовые коробочные системы закрывают 80% типовых сценариев. Остальные 20% либо решают через мучительную настройку, либо через кастомную разработку. Обычно дешевле сразу сделать своё, чем полгода бороться с ограничениями чужой платформы.
B2B-портал и маркетплейс
Платформа, где несколько сторон взаимодействуют между собой: продавцы и покупатели, заказчики и исполнители, арендодатели и арендаторы. Разные роли, разные права, разные интерфейсы. Это серьёзная инженерная задача, которая требует продуманной архитектуры с самого начала.
Пример из моей практики: ТендерОК. Строительные компании загружают пакет тендерной документации, система разбирает документы, считает себестоимость и рекомендует ставку. Я вёл проект как fullstack от идеи до боевой версии на tenderok.pro. Это как раз тот случай, когда готовый инструмент не существует в природе.
Когда НЕ нужна разработка веб-приложения. Если задача решается конструктором или no-code, я так и скажу. Лендинг под один продукт, витрина на двадцать товаров, корпоративный сайт с формой обратной связи: здесь кастом избыточен и только дороже. Разработку приложения имеет смысл заказывать, когда есть реальная бизнес-логика: роли, права, обработка данных, интеграции. И когда проект рассчитан на рост, а не на вечное существование в неизменном виде.
Ещё одна честная граница: если для реализации нужна команда из 5+ специалистов одновременно, solo-разработка не подойдёт по срокам. И если проект требует enterprise-compliance с сертификациями и формальными процессами: это уже зона крупных интеграторов.
SPA, SSR, PWA: что выбрать под задачу
Выбор архитектуры рендеринга влияет на скорость, SEO и стоимость поддержки. Кратко про три основных варианта, и когда что беру я.
SPA (single-page application) живёт целиком в браузере, рендерит страницы через JavaScript без перезагрузок. Хорошо для насыщенных интерфейсов за логином, где SEO неважно: дашборды, редакторы, внутренние системы. Плохо, если нужна индексация публичных страниц.
SSR (server-side rendering) отдаёт готовый HTML с сервера. Первый экран быстрый, поисковик видит контент сразу. Нужен живой сервер на каждый запрос. Это мой основной выбор для приложений с публичной частью, где SEO важно, или когда первый экран критичен по скорости.
PWA (progressive web app) это надстройка над вебом: офлайн-режим, установка на устройство, push-уведомления без App Store. Не отдельная архитектура, а дополнительный слой. Беру, когда мобильный опыт критичен, а строить нативное приложение избыточно дорого.
На практике современные проекты смешивают режимы: публичная часть идёт через SSR, личный кабинет работает как SPA, критичные страницы генерируются статически. Nuxt и Next.js позволяют это делать per-route, не на уровне всего приложения.
Подробнее о видах веб-приложений и том, как работает каждый из них под капотом, я разобрал в отдельной статье: что такое веб-приложение.
Этапы разработки веб-приложения на заказ
Описываю реальный процесс, не студийный шаблон с красивыми названиями фаз.
Аналитика и ТЗ
Начинается с понимания задачи, а не сразу с кода. Что делает приложение, кто пользователи, какие сценарии ключевые, что должно работать в первой версии, а что можно отложить. На этом этапе выявляем неочевидные сложности, о которых заказчик не думал: интеграции с внешними системами, логика прав, граничные случаи в бизнес-процессе.
Результат: техническое задание с описанием сущностей, ролей, ключевых сценариев и API-контрактов. Не документ ради документа, а рабочий артефакт, по которому потом принимается работа.
Прототип и дизайн
Wireframes основных экранов, иногда кликабельный прототип в Figma. На этом шаге выясняется половина «а это мы не подумали». Это хорошо, потому что переделать прототип дешевле, чем переписать код.
Дизайн делаю сам или привлекаю дизайнера: зависит от требований к визуалу. Для MVP с понятной аудиторией часто хватает чистого функционального дизайна без дорогой графики.
Разработка: фронтенд и бэкенд параллельно
После утверждения прототипа начинается основная работа. Фронтенд и бэкенд разрабатываются параллельно по заранее согласованным API-контрактам. Это позволяет не ждать, пока один слой полностью готов, прежде чем начать другой.
Работаю итерациями: каждые 1–2 недели есть рабочий инкремент, который можно потрогать и дать обратную связь. Не «приходите через три месяца, смотрите готовый продукт».
Тестирование и релиз
Ручное тестирование всех ключевых сценариев, включая граничные случаи. Для критичных частей пишу автотесты. Настройка окружения: Docker-контейнер, CI/CD-пайплайн, мониторинг ошибок.
Релиз это не конец, а начало следующего цикла. Первые две недели после запуска обязательно держу связь плотнее обычного: реальные пользователи находят то, что тест не нашёл.
Поддержка и развитие
После релиза проект не замирает. Баги, небольшие доработки, новые фичи по мере роста продукта. Договариваемся на старте: либо отдельный ретейнер, либо по факту обращений.
| Этап | Что входит | Длительность (solo) |
|---|---|---|
| Аналитика и ТЗ | Бриф, сценарии, сущности, API-контракты | 1–2 недели |
| Прототип и дизайн | Wireframes, UI в Figma, согласование | 1–2 недели |
| Разработка (фронт + бэк) | Параллельные треки, итерации 1–2 недели | 3–10 недель |
| Тестирование и релиз | QA, Docker, CI/CD, деплой | 1–2 недели |
| Поддержка | Баги, доработки, развитие | Ongoing |
Технологический стек: что и почему
Здесь расскажу не про «мы используем современные технологии», а про конкретные выборы и реальные причины.
Фронтенд: Vue/Nuxt vs React/Next. Когда что беру
Nuxt и Vue это мой основной стек. Nuxt даёт SSR из коробки, встроенный роутинг, удобную работу с серверными функциями через server routes, и при этом не перегружает проект боilerplate'ом. Vue читается чище React, особенно когда в команде не только опытные разработчики. Composition API начиная с Vue 3 закрывает почти любую задачу по логике компонентов.
React и Next.js беру, когда проект уже строится на React-экосистеме, или когда заказчику важна конкретная UI-библиотека, которая есть только в мире React. Next.js хорошо подходит большим командам, где уже есть React-опыт. У него огромная экосистема и хорошая документация.
Честно о том, что не люблю: Angular на небольших проектах избыточен. Он тащит за собой много концепций, которые оправданы в enterprise, но убивают скорость на MVP. Работал с ним в прошлом, выбираю осознанно не брать под новые проекты размера, с которым работаю я.
Бэкенд и база данных
Node.js при работе на Nuxt/Vue это естественный выбор. Один язык на весь стек, переиспользование типов между фронтом и бэком, удобная работа с async/await. Для небольших проектов отлично работают Nuxt server routes: не нужен отдельный сервер, логика живёт рядом с фронтендом.
Когда нужен отдельный бэкенд (сложная логика, несколько клиентов, независимое масштабирование), пишу на Node.js с TypeScript. Для совсем тяжёлой вычислительной нагрузки смотрю в сторону Go, но это редкость в задачах, которые ко мне приходят.
PostgreSQL это основная база, которую беру по умолчанию. Надёжная, мощная, прекрасно работает с JSON-полями когда нужна гибкость схемы, поддерживает полнотекстовый поиск. Supabase беру на проектах, где нужно быстро стартовать: даёт базу, авторизацию и realtime из коробки, и это экономит 1–2 недели только на инфраструктуре. На раннем MVP это разумный способ не тратить время на инфраструктуру, которую всё равно перепишешь при росте.
Инфраструктура и деплой
Docker это стандарт. Контейнеризация убивает проблему «у меня работает, на сервере нет», и мои деплои воспроизводимы. GitHub Actions для CI/CD: пуш в main, автосборка, тест, деплой на сервер. Настраиваю на каждом проекте, потому что ручной деплой ошибается и теряет время.
Хостинг выбираю под задачу. VPS на Aeza или другом провайдере под Caddy как reverse proxy: работает хорошо, предсказуемо, стоит дёшево. Cloudflare ставлю перед сервером для защиты и кеша. Vercel и похожие платформы удобны для фронтенда, но имею опыт, когда они создают проблемы на специфических нагрузках.
Сроки разработки: реальные цифры
Сроки, которые я называю реально, а не те, которые звучат красиво на переговорах.
| Тип проекта | Диапазон сроков | Что влияет |
|---|---|---|
| MVP: 1–2 роли, базовая логика | 4–8 недель | Чёткость требований, число интеграций |
| Средний SaaS/CRM: 3–5 ролей, платежи | 2–4 месяца | Сложность бизнес-логики, API-интеграции |
| Сложный продукт: биллинг, аналитика, мультитенант | 4–6 месяцев | Архитектурные решения, объём тестирования |
| B2B-портал / маркетплейс | 4–8 месяцев | Число сторон, транзакционная логика |
Главный враг сроков: размытые требования. Если ТЗ меняется каждую неделю, сроки уходят вправо неизбежно. Второй враг: «добавим ещё одну небольшую фичу», которая на деле затрагивает архитектуру. Третий: долгие согласования на стороне заказчика: если ждать правок неделями, итерация растягивается в разы.
Сколько стоит разработка веб-приложения на заказ
Из чего складывается стоимость
Цена не берётся с потолка. Смотрю на несколько факторов.
Объём логики и число ролей. Простой кабинет с одним типом пользователя и тремя-четырьмя действиями сильно дешевле системы, где есть администратор, менеджер, клиент и каждый видит своё.
Интеграции. Подключить оплату через ЮKassa занимает время. Двусторонний обмен с 1С: отдельный проект внутри проекта. Каждая внешняя система добавляет сложности, которую нельзя сжать.
Сложность интерфейса. Простые экраны с формами и таблицами vs. дашборд с интерактивными графиками, drag-and-drop, real-time обновлениями.
Архитектурные требования. Мультитенантность, горизонтальное масштабирование, высокая нагрузка. Всё это усложняет и удорожает.
Ценовые вилки по типам проектов
Мои реальные цифры. Ниже студийных «от 500 тысяч», потому что нет прослойки менеджеров, аккаунтов и офиса. Вы платите за разработку, а не за структуру агентства.
| Тип проекта | Solo-диапазон | Что включено |
|---|---|---|
| MVP, личный кабинет (1–2 роли) | от 100 000 ₽ | Базовая логика, аутентификация, простой UI |
| Сервис среднего размера (3–5 ролей, платежи) | 250 000 – 600 000 ₽ | Биллинг, интеграции, расширенный UI |
| Сложный SaaS, B2B-платформа | 600 000 – 1 500 000 ₽ | Мультитенант, аналитика, нагрузка |
| Выше 1,5 млн ₽ | нужна команда | Объём превышает solo-возможности |
Минимальный порог: 100 000 рублей. Это не произвольная цифра: ниже него не получается построить ничего, что потом не придётся переписать. Конструкторы работают ниже этой суммы и решают другие задачи.
Фиксированная цена vs Time and Material
Фиксированная цена работает хорошо, когда требования конкретные и согласованные до начала работ. Вы знаете, что получите, я знаю, что делать. Риск: любые изменения требований идут через согласование допников.
+Плюсы
- Прозрачный бюджет, нет сюрпризов в счёте
- Чёткий объём, понятный критерий приёмки
- Защита от scope creep: хочешь больше, обсуждаем отдельно
−Минусы
- Требует детального ТЗ на старте
- Изменения требований затрудняются и удорожаются
- Жёсткий стек решений до начала разработки
Time and Material подходит для проектов с живыми требованиями: когда продукт нащупывается в процессе, направление может измениться по результатам пользовательского тестирования, или объём неизвестен заранее.
+Плюсы
- Гибкость: можно менять приоритеты между итерациями
- Платите за реально сделанную работу
- Быстрый старт без написания полного ТЗ
−Минусы
- Бюджет менее предсказуем
- Требует доверия и хорошей коммуникации
- Нужно следить за расходом часов
На практике чаще всего делаю гибрид: фиксированная стоимость на ясные фазы (аналитика, дизайн, MVP), T&M на развитие после релиза.
Студия, агентство или solo-разработчик: что выбрать
Честный разбор без саморекламы. У каждого варианта есть своё место.
Solo-разработчик (как я):
+Плюсы
- Прямая коммуникация: нет менеджеров-посредников, решения принимаются быстро
- Дешевле за счёт отсутствия агентской наценки
- Один человек держит весь контекст проекта
- Гибкость в выборе стека и подходов
−Минусы
- Ограниченная пропускная способность: одновременно веду 1–2 проекта
- Нет параллельных треков на 5+ специалистов
- Если solo заболел или занят, проект ждёт
- Для очень большого объёма нужна команда
Студия / агентство:
+Плюсы
- Команда специалистов: дизайнер, frontend, backend, тестировщик одновременно
- Процессы, юридическая защита, договорная история
- Подходит для больших параллельных задач
−Минусы
- Дороже: оплачивается структура агентства
- Коммуникация через менеджера часто теряет нюансы
- Смена команды на проекте теряет контекст
- «Продают» один уровень, «делает» другой
Мой честный ответ: solo-разработчик оптимален для MVP и проектов до 6 месяцев, где важна скорость коммуникации и разумная цена. Студия нужна, когда объём реально требует 5+ специалистов одновременно или когда нужна формальная структура с многоуровневым согласованием.
Как заказать разработку веб-приложения: что подготовить
Не нужно приходить с готовым ТЗ на 50 страниц. Нужно прийти с пониманием задачи.
Что полезно подготовить:
- Описание задачи. Что делает приложение? Для кого? Какие сценарии ключевые? Достаточно 1–2 страниц в свободной форме.
- Примеры и референсы. Какие продукты нравятся по функционалу или дизайну. Не обязательно из той же отрасли.
- Бюджетный диапазон. Хотя бы приблизительно. Это помогает сразу предложить реальный объём MVP вместо фантазийного продукта на бесконечный бюджет.
- Роли на стороне клиента. Кто принимает решения по продукту? Кто будет давать обратную связь по макетам? Кто будет принимать работу? Чем меньше согласующих, тем быстрее движется проект.
- Ограничения и интеграции. Есть ли уже используемые системы, с которыми нужно связываться (CRM, 1С, платёжный шлюз)?
После брифа я даю оценку: реально ли это вписывается в названный бюджет, где основные риски, что можно отложить на вторую итерацию. Без продажи того, что не нужно.
Если хочешь обсудить задачу, переходи на страницу разработки веб-приложений: там описан процесс работы и можно оставить заявку.
