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

За 13 лет в Surf мы запустили больше сотни веб-приложений — от личного кабинета IZZI для миллиона абонентов до ERP-системы KFC на 800+ ресторанов. Этот гайд — сжатая выжимка того, что мы поняли за эти годы: как не слить бюджет, где обычно ломается проект и какие решения имеют значение, а какие — нет.

Материал написан для заказчика, а не для разработчика. Вы поймёте, как устроена разработка, чтобы уверенно вести переговоры с подрядчиком и принимать решения, от которых зависит судьба продукта. Если вы СТО или архитектор — вам тут будет скучно, это гайд для бизнеса.

Внутри: 5 этапов от Discovery до релиза, сравнение фронт- и бэкенд-стеков, вилки цен и сроков в рублях, состав команды, чек-лист запуска, кейсы и FAQ. Прочитать можно линейно или ткнуть в нужный раздел в оглавлении — материал спроектирован и для того, и для другого.

Короткое замечание про терминологию. Мы используем «веб-приложение» как собирательное понятие: личные кабинеты, B2B-порталы, CRM, ERP, PWA, SPA, e-com-платформы с нетривиальной логикой. Визитки и лендинги — это другая работа, и ниже мы отдельно объясняем, где проходит граница.

Что такое веб-приложение и кому нужен этот гайд

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

Этот гайд вам полезен, если:

• вы собираетесь запустить личный кабинет, CRM, портал или e-com с нестандартной логикой;
• у вас уже есть MVP на Tilda/Битриксе, и вы упёрлись в потолок шаблонов;
• вам дали три КП от разных студий, и вилка отличается в 4 раза — хочется понять, за что платите;
• внутри компании идёт спор «React или Vue», «монолит или микросервисы», и нужно нейтральное мнение;
• собираете бюджет на 2026 и нужны правдоподобные цифры для защиты перед советом директоров.

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

Веб-приложение vs сайт vs портал — что выбрать под задачу

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

Короткое правило:

• пользователь заходит «почитать» — это сайт;
• пользователь заходит «что-то сделать» — веб-приложение;
• пользователь «работает часами с разными ролями и правами» — портал.

Если в вашем проекте есть пересечения (например, сайт + личный кабинет) — это нормально, в Discovery вы разложите продукт на части и для каждой выберете свой подход. Оставшаяся часть гайда — про средний и правый столбцы таблицы.

Этап 1. Discovery — предпроектное исследование

Сроки: 2–4 недели.

Команда: PM, бизнес-аналитик, ведущий архитектор, UX-лид, иногда продуктовый дизайнер.

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

Discovery — это когда команда подрядчика и заказчик садятся вместе и отвечают на вопросы, на которые в брифе ответов не хватает. Какую проблему бизнеса решаем, у кого, как мы узнаем, что получилось, какие есть ограничения (регуляторика, интеграции, наследие), какую часть делаем в MVP, а какую — в релиз 2.

Звучит как «давайте потратим месяц на разговоры» — и именно это останавливает многих от Discovery. Честно говоря, так и есть: на этом этапе код не пишут. Но исправить ошибку, найденную на Discovery, стоит в 10–100 раз дешевле, чем ту же ошибку, найденную после релиза. Это не метафора — это чистая математика переделки: переписать архитектуру дороже, чем нарисовать её иначе.

Что выходит на руки заказчику:

1. Концепция продукта на 10–20 слайдов — чтобы вся команда и совет директоров одинаково понимали, что мы делаем.
2. Карта пользовательских сценариев — для каждой роли показаны её задачи в приложении.
3. Каркасные прототипы (wireframes) 10–20 ключевых экранов — без дизайна, для сверки логики.
4. Техническое задание на 40–80 страниц — с функциональными требованиями, ролевой моделью, ограничениями.
5. Архитектурная схема — верхнеуровневая, с обозначением интеграций и инфраструктуры.
6. Смета и роадмап — с декомпозицией по спринтам, с вилкой «оптимистично/реалистично/пессимистично».

Красный флаг: если подрядчик предлагает фикс-цену без Discovery, значит, он либо заложил 30% риска сверху, либо через месяц придёт с доплатами. Оба варианта плохие. Мы в Surf сначала делаем Sprint Zero (наш формат Discovery, 2–4 недели, от 400 тыс. ₽), а уже по его итогам даём точную смету на разработку.

Этап 2. UX-проектирование

Сроки: 3–6 недель, параллельно с UI (часть задач).

Команда: UX-дизайнер, продуктовый аналитик, иногда — исследователь, PM.

Результат: user flow, детальные wireframes, интерактивный прототип.

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

Ключевая работа UX-дизайнера в веб-приложении — не главный экран (он обычно прост), а сложные таблицы, многошаговые формы, админка, пустые состояния, ошибки. Если в UX-проекте есть только «красивый дашборд» без проработки списков/фильтров/пустых состояний — это плохой знак.

Что полезно запросить на этом этапе:

• интерактивный прототип в Figma, по которому можно «кликать» и почувствовать продукт;
• проработку хотя бы двух сложных сценариев end-to-end (например, «оформление заказа с промокодом и оплатой в рассрочку»);
• UX-документ с логикой форм, валидаций, состояний ошибок;
• мобильную адаптацию — минимум для сценариев, которые будут использоваться с телефона.

Практика Surf: мы всегда тестируем прототип на 3–5 живых пользователях до начала UI. Это стоит от 50 тыс. ₽ и экономит 500+ тыс. ₽ на переделках после релиза. Почти всегда после тестов мы что-то меняем — это нормально, это и есть смысл этапа.

Этап 3. UI-дизайн

Сроки: 4–10 недель, в зависимости от сложности дизайн-системы.

Команда: UI-дизайнер, арт-директор, моушен-дизайнер (опционально).

Результат: дизайн-система, макеты всех ключевых экранов, все состояния.

На этом этапе у приложения появляется «лицо»: цвета, шрифты, иконки, компоненты, микроанимации. Но главный артефакт этапа — не красивые картинки, а дизайн-система: библиотека компонентов (кнопки, инпуты, модалки, таблицы, карточки), которую фронтенд-разработчики превратят в живой UI-кит на коде.

Без дизайн-системы каждый экран будет делаться с нуля, разработчики будут дублировать код, интерфейс потеряет единообразие уже к 30-му экрану. Если на вашем проекте планируется больше 20 уникальных экранов — дизайн-система обязательна.

Что должно быть в сдаче:

1. Дизайн-токены (цвета, типографика, тени, радиусы) — с привязкой к переменным.
2. Компоненты в Figma — с автолейаутом, вариантами (primary/secondary/disabled), состояниями (hover/focus/error).
3. Все ключевые экраны в десктопной и мобильной версии.
4. Все состояния: загрузка, ошибка, пусто, много данных, офлайн.
5. Спецификации для разработчиков (spacing, размеры, поведение).

Вопрос, который стоит задать дизайнеру: «Покажите мне экран с пустым состоянием и экран с ошибкой валидации формы». Если ответ — «нет, до этого не дошли» — работа не готова, макеты пока декоративные.

Этап 4. Разработка

Сроки: 3–9 месяцев в зависимости от объёма.

Команда: фронтенд-разработчики (2–4), бэкенд-разработчики (2–4), QA (1–2), DevOps (0,5), аналитик (0,5), PM, тимлид.

Результат: работающий продукт на dev-, stage- и prod-окружениях.

На этом этапе проект переходит из Figma в код. Параллельно идут три потока — фронт, бэк и QA — с общим ритмом в 2-недельных спринтах. В конце каждого спринта — демо для заказчика.

Архитектурно мы делим работу на два слоя: фронтенд (то, что видит пользователь в браузере) и бэкенд (логика, база данных, интеграции). Они общаются через API (обычно REST или GraphQL). В крупных проектах добавляются микросервисы, очереди сообщений, кеши, поиск — но это уже нюансы, к которым мы придём в разделе «Архитектура».

Фронтенд. React vs Vue vs Angular vs Next.js — когда что

На 2026 год на российском рынке доминирует четвёрка фронтенд-решений: React, Vue, Angular и Next.js. Вот короткая карта, когда что имеет смысл.

Коротко по выбору:

• нужен SEO и быстрые первые экраны — Next.js;
• делаете SPA-инструмент (без SEO) — React или Vue;
• сложный enterprise с 10+ фронтами в команде — Angular или React + строгий архитектурный шаблон;
• стартап, MVP за 3 месяца — Vue с Nuxt или Next.js.

В Surf у нас в работе одновременно все четыре: на KFC ERP и банковских проектах — React + TypeScript, на Бетховене — Next.js, на нескольких PWA и MVP — Vue. Технология выбирается под задачу и под команду, а не «потому что мы всегда делаем на X».

Бэкенд. Node.js vs Python vs Kotlin vs Go — когда что

Мы в Surf работаем со всеми четырьмя. Это не понты — это следствие того, что в разных проектах нужны разные гарантии. В KFC ERP — Kotlin+Spring, потому что нам нужны были транзакции, интеграция с SAP и корпоративный уровень надёжности. На IZZI — Python, потому что исторически бэкенд провайдера на нём. На ряде PWA — Node.js, потому что команда экономит время, не переключая контекст с фронта.

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

Базы данных — короткий ориентир

• PostgreSQL — дефолт для 90% веб-приложений в 2026. Бесплатный, надёжный, расширяемый.
• MySQL / MariaDB — если исторически уже используется.
• MongoDB — когда структура данных сильно меняется или важна гибкая схема (контентные сервисы).
• Redis — кеш, очереди, rate-limiting. Не основная БД.
• ClickHouse — аналитика, логи, биллинг, когда данных миллиарды строк.
• Elasticsearch / OpenSearch — полнотекстовый поиск, фасетные фильтры в каталогах.

В большинстве веб-приложений достаточно одной PostgreSQL и одного Redis. Всё остальное добавляется по мере роста нагрузки.

Что ещё закладывается на этапе разработки

• CI/CD (GitLab CI, GitHub Actions) — автоматическая сборка и деплой с первого дня.
• Логирование и мониторинг (Prometheus, Grafana, Sentry) — до релиза, не после.
• Тесты (unit + integration + e2e) — 60–80% покрытия критичных сценариев.
• Документация API (OpenAPI/Swagger) — автогенерация из кода.
• Feature flags — чтобы релизить фичи постепенно, а не «всё сразу на всех».

Если подрядчик не закладывает CI/CD, тесты и мониторинг «по умолчанию», а предлагает как отдельную услугу «для продвинутых» — это тревожный сигнал. Это базовая гигиена 2026-го.

Итак, продукт собран. Но пока его не протестировали и не выкатили — это не релиз, это коробка кода. Едем дальше.

Этап 5. Тестирование и релиз

Сроки: 2–6 недель (часть идёт параллельно разработке).

Команда: QA-инженеры, DevOps, security-специалист, PM.

Результат: приложение на проде, мониторинг, алерты, бэкапы, документация, план развития.

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

Что должно быть протестировано до релиза:

• Функциональные сценарии — по чек-листу на каждый сценарий из ТЗ.
• Кросс-браузерность — Chrome, Safari, Firefox, Edge, Yandex, последние 2 версии.
• Адаптив — минимум desktop и mobile, часто tablet.
• Нагрузка — эмуляция целевого трафика и пика (обычно x3 от среднего).
• Security — OWASP Top-10: SQL-инъекции, XSS, CSRF, логика авторизации, обработка загруженных файлов.
• Производительность — Time To First Byte, Largest Contentful Paint, Core Web Vitals.
• Доступность — хотя бы минимум WCAG 2.1 AA для публичных продуктов.

Деплой и инфраструктура: обычно выкатываемся по схеме dev → stage → prod, с откатами через blue-green или canary. CDN, SSL, бэкапы БД с retention на 30 дней, мониторинг с алертами в Slack/Telegram — всё это настраивается до релиза, не после.

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

Архитектура: монолит vs микросервисы vs serverless

Это тема, где заказчики чаще всего получают противоречивые советы. Одна студия кричит «только микросервисы, это 2026 на дворе», другая — «микросервисы вас убьют, делайте монолит». Истина, как обычно, в деталях.

Наш опыт в Surf: в 80% проектов мы стартуем с модульного монолита. Это даёт скорость разработки монолита плюс готовую «точку распила» на микросервисы, когда команда реально вырастет. Прыгать в микросервисы с команды из 5 человек — частая и дорогая ошибка: вы будете тратить 40% времени не на продукт, а на инфраструктуру. Микросервисы — это не «быстрее» или «модно», это инструмент для команд 30+, когда организационная сложность перевешивает техническую.

Команда веб-проекта — кто и за что отвечает

Минимальный состав для среднего веб-приложения (около 30 экранов):

• Project Manager (PM) — держит сроки, бюджет, коммуникацию.
• Бизнес-аналитик — пишет и поддерживает ТЗ, помогает приоритизировать.
• UX-дизайнер — проектирует сценарии и wireframes.
• UI-дизайнер — дизайн-система, макеты.
• 2 Frontend-разработчика — обычно тимлид + мидл.
• 2 Backend-разработчика — тимлид + мидл.
• QA-инженер — ручное и авто-тестирование.
• DevOps (частично, 0,5 FTE) — CI/CD, инфраструктура.

Для крупного портала добавляются: архитектор, второй QA (авто- и нагрузочные тесты), security-специалист, технический писатель, техлид/CTO как контрольная точка.

Типичные заблуждения:

• «Можно обойтись без PM, я сам буду вести проект». Можно. Но через 2 месяца вы утонете в 40 задачах в Jira, и продукт начнёт плыть. PM — это не расход, это страховка.
• «Можно без дизайнера, есть шаблон Bootstrap». Для внутреннего инструмента на 5 экранов — да. Для продукта с живыми пользователями — нет: шаблонный UI бьёт по конверсии и по восприятию бренда.
• «Один разработчик за всё». Кратковременно возможно, но проект становится bus-factor = 1: если человек уйдёт в отпуск или заболеет — всё встанет.

Сколько стоит веб-приложение в 2026

Вилка по российскому рынку на 2026 год:

Что влияет на цену внутри вилки:

• количество ролей в ролевой модели (каждая роль — это отдельный UX-сценарий и отдельный набор прав);
• количество интеграций (каждая внешняя система — от 100 до 500 тыс. ₽);
• требования к безопасности (PCI DSS, 152-ФЗ, банковская регуляторика — это +30–50% к бюджету);
• сложность UX (простая форма vs многошаговый конфигуратор);
• нагрузка (10 пользователей в день vs 100 000 в пике);
• требования к SLA после релиза (99% vs 99,99% — разница в инфраструктуре и процессах).

Дополнительно к разработке:

• Discovery (Sprint Zero) — 300–800 тыс. ₽;
• дизайн-система — 400 тыс. — 1,5 млн ₽, если делается отдельно;
• нагрузочное и security-тестирование — 200–600 тыс. ₽;
• сопровождение первого месяца после релиза — обычно 10–15% от стоимости разработки.

Честное признание. Если вам называют цену «1,5 млн ₽ за ERP» — это либо шаблон из коробки под видом заказной разработки, либо демпинг с ожидаемыми доплатами в процессе. Ни то, ни другое не то, что вам нужно.

Сроки разработки по типам проектов

Что ускоряет проект:

• готовая дизайн-система или брендбук;
• собранные пользовательские сценарии и интервью на старте;
• один decision maker на стороне клиента, а не комитет из 7 человек;
• доступ к интеграционным системам с первого дня, а не «дадим, когда дойдём».

Что замедляет:

• долгие согласования на стороне клиента (каждая неделя ожидания = неделя простоя команды);
• добавление новых фич в процессе без пересмотра сроков;
• корпоративные СБ-процедуры для выдачи доступов к тестовым контурам;
• меняющиеся требования регулятора (в банковских и медицинских продуктах).

Поддержка после релиза — SLA и стоимость

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

Типичные пакеты поддержки:

Что важно зафиксировать в договоре на поддержку:

• время реакции на инциденты разного уровня критичности (P1/P2/P3);
• часы работы поддержки (8×5 vs 24×7);
• каналы связи (горячая линия, Slack, email, тикетница);
• стоимость часа на внеплановые работы;
• процедура передачи знаний, если вы решите сменить подрядчика через год.

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

Когда заказчик решает забрать продукт во внутреннюю команду — это тоже нормальная и предусмотренная сценарием история. Передача занимает 4–8 недель: совместные созвоны на код-ревью, документация по архитектуре, инструкции по деплою, тренинги по бизнес-логике. К моменту прощания у инхаус-команды есть всё, чтобы продолжить, а не разобраться с нуля.

7 кейсов Surf: как это выглядит на практике

Чтобы гайд не выглядел теорией, покажем, как 5 этапов и выбор стека работают на реальных проектах разной природы — от ERP до B2B-маркетплейса и финтеха.

KFC — ERP для управления сетью

Задача: объединить 800+ франчайзинговых ресторанов в единую ERP с интеграцией в SAP, производство, логистику.

Стек: React + TypeScript (фронт), Kotlin + Spring (бэк), PostgreSQL, RabbitMQ.

Архитектура: микросервисы, потому что команда на пике доходила до 40+ человек, и нужны были независимые релизы модулей.

Сроки: больше года, с фазовым рилизом — сначала пилот 10 ресторанов, потом 100, потом вся сеть.

Что важно: уровень SLA enterprise — 99,9%, интеграция с унаследованными системами SAP, где одна ошибка в транзакции стоит денег. Именно здесь выбор Kotlin + Spring оправдан: безопасность, транзакции, зрелость JVM.

The Hole (Medium Quality) — CRM + портал

Задача: креативное агентство Medium Quality нуждалось во внутренней CRM для управления проектами и внешнем портале для клиентов — чтобы заказчики видели статусы, согласовывали брифы, смотрели рендеры.

Стек: Next.js (фронт + SSR), Node.js (бэк), PostgreSQL.

Архитектура: модульный монолит. Команда маленькая (5–7 человек), нагрузка предсказуемая, микросервисы тут только ухудшили бы скорость разработки.

Сроки: 5 месяцев от Discovery до релиза.

Что важно: дизайн-система стала продолжением фирстиля агентства. Это кейс, где UI-уровень — не декор, а часть бренда.

IZZI — личный кабинет провайдера на миллион абонентов

Задача: заменить колл-центр на self-service — чтобы абоненты сами решали 80% вопросов (тарифы, оплата, технические проблемы, подключение услуг).

Стек: Vue + Nuxt (фронт), Python (бэк, исторически), PostgreSQL, Redis.

Архитектура: модульный монолит с вынесением отдельных тяжёлых узлов в микросервисы (биллинг, авторизация).

Сроки: 8 месяцев, потом ещё 6 месяцев на фичи второй очереди.

Что важно: миллион пользователей — это не «много», это «нужна инфраструктура другого уровня». CDN, кеши, балансировка, graceful degradation — всё это проектировалось с нуля.

IZZI Business — B2B-маркетплейс автоуслуг

Задача: дать партнёрам IZZI (точки шиномонтажа и автомойки) самостоятельно управлять своим присутствием на маркетплейсе — редактировать карточки точек, расписание постов, услуги и тарифы — без обращений в саппорт.

Стек: Vue + Nuxt (фронт), Node.js (бэк), PostgreSQL.

Архитектура: SPA с трёхуровневой ролевой моделью (партнёр-владелец, администратор точки, диспетчер).

Сроки: 5 месяцев.

Что важно: B2B SaaS — это не «дайте красивый интерфейс», а «дайте инструмент, в котором партнёру удобнее работать, чем в Excel». Поэтому ключевой работой был UX сложных таблиц, многошагового онбординга и расписаний — а не главный экран. Этот кейс — продолжение бренда IZZI: B2C-кабинет абонентов сверху и B2B-маркетплейс для партнёров снизу, на общей продуктовой инфраструктуре.

Росбанк — PWA как альтернатива мобильному приложению

Задача: сегмент клиентов, для которого установка нативного приложения — барьер (иностранные пользователи, владельцы «серых» Android без Google Play, редкие визитёры).

Стек: React + Next.js, Node.js BFF, банковский бэкенд через API.

Архитектура: PWA с полноценным service worker, офлайн-хранилищем, push-уведомлениями.

Сроки: 6 месяцев.

Что важно: PWA в банковском сегменте требует особого внимания к безопасности — шифрование локальных хранилищ, короткие сессии, биометрия через WebAuthn. Подробнее о PWA.

Бетховен — e-com с интеграцией маркетплейсов и программы лояльности

Задача: единая платформа для продажи зоотоваров через сайт, маркетплейсы (Ozon, Wildberries), физические магазины — с общей программой лояльности.

Стек: Next.js (фронт и SSR, потому что SEO — ядро бизнеса), Node.js и Python (бэк), PostgreSQL + ClickHouse для аналитики, Elasticsearch для поиска по каталогу.

Архитектура: микросервисы для критичных доменов (каталог, заказы, лояльность), монолитная административная часть.

Сроки: 10 месяцев до первого релиза, развитие продолжается.

Что важно: SEO — ключевой канал трафика, поэтому Next.js с SSR и строгая работа с метаданными, sitemap, Schema.org. Без этого вся инвестиция в каталог превратилась бы в закрытое приложение без органики.

Финтех-стартап под NDA — веб-клиент платёжной системы

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

Стек: React + TypeScript (фронт), Node.js (бэк), PostgreSQL.

Архитектура: микросервисы на критичных доменах — платёжный шлюз, KYC-модуль, антифрод, админка — каждый в своей зоне ответственности и со своим релизным циклом.

Сроки: 4 месяца до MVP, дальнейшее развитие.

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

Если хочется увидеть больше — все веб-кейсы на сайте. А рейтинг веб-студий 2026 поможет сравнить Surf с альтернативами.

Чек-лист запуска: что должно быть готово перед релизом

Перед тем как нажать кнопку «в прод», пройдитесь по этому списку. Если по любому пункту ответ «не уверен» — откладывайте релиз.

Инфраструктура:

• SSL-сертификат и автообновление.
• CDN настроен, статика отдаётся через него.
• Резервное копирование БД: автоматическое, с retention, с тестом восстановления.
• Мониторинг доступности (uptime) с алертами.
• Мониторинг производительности (APM): Sentry / NewRelic / аналог.
• Логирование: централизованное, с поиском, с retention.
• CI/CD: сборка и деплой автоматизированы, нет «задеплоил вручную».
• Откат: процедура возврата на предыдущую версию за 5 минут.

Безопасность:

• Пройден OWASP Top-10 чек-лист.
• Секреты хранятся в vault, не в коде.
• Rate-limiting на публичные API.
• HTTPS-only, HSTS включён.
• 2FA для админов.
• Security-аудит (хотя бы внутренний) пройден.

SEO и аналитика:

• Metadata, robots.txt, sitemap.xml, schema.org.
• Аналитика (Яндекс.Метрика / GA / аналог) подключена и проверена на тестовых событиях.
• Пиксели CRM, рекламы — если нужны.
• Core Web Vitals в зелёной зоне на ключевых страницах.

Контент и юридические:

• Согласие на cookies, политика конфиденциальности, пользовательское соглашение.
• 152-ФЗ соответствие, если работаете с персональными данными россиян.
• 404-я и 500-я страницы оформлены.
• Нет заглушек вроде «Lorem ipsum» или «тестовый текст».

Процессы:

• Процедура приёма инцидентов расписана.
• Документация для поддержки передана.
• Дежурная команда первой недели назначена.
• План релиза с таймингом и ответственными у всех на руках.

Типичные ошибки при разработке веб-приложений

13 лет в отрасли научили нас, где проекты чаще всего ломаются. Вот топ-10, собранный из собственных граблей и чужих историй.

1. Пропустить Discovery. «Мы всё знаем, давайте сразу кодить». Через 3 месяца выясняется, что архитектура не учитывает ролевую модель, и надо переписывать 30% бэка.

2. Фикс-цена на этапе, когда ТЗ ещё не готово. Подрядчик либо заложил 30% риска сверху, либо будет экономить на качестве. T&M или Agile Fixed Price — честнее.

3. Выбирать стек «потому что модно». Микросервисы на команде из 5 человек. Go там, где хватило бы Node.js. Angular на проекте, где через год не найти разработчика в регионе.

4. Игнорировать дизайн-систему. К 30-му экрану интерфейс разваливается, разработчики дублируют код, правки занимают x3 времени.

5. Тестировать только в финале. Баги, найденные за неделю до релиза, стоят в 10 раз дороже, чем найденные в спринте.

6. Откладывать CI/CD «на потом». «Потом» не наступает. Через 3 месяца у вас 200 коммитов без автосборки и страх релизов.

7. Писать ТЗ раз и навсегда. Продукт живой, требования меняются. ТЗ — это рабочий документ, он должен обновляться с каждым спринтом.

8. Запускать продукт без мониторинга. После релиза вы узнаёте о проблемах от пользователей в соцсетях. Это дорогая реклама.

9. Недооценивать нагрузочное тестирование. «У нас всего тысяча пользователей в день». А когда запустите промо — будет 50 тысяч. Приложение упадёт в первый же час.

10. Менять подрядчика в середине проекта. Иногда это необходимо, но это всегда −30% к бюджету и +3 месяца к срокам. Подумайте десять раз.

Ответы на частые вопросы

Чем веб-приложение отличается от сайта?

Сайт даёт информацию, веб-приложение решает задачи. Если пользователь возвращается снова и снова, чтобы что-то сделать (оплатить, заказать, согласовать) — это веб-приложение. Если заходит один раз почитать — сайт.

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

Простое SPA — 500 тыс. — 1,5 млн ₽. Личный кабинет / MVP — 1,5–3 млн ₽. Средняя CRM — 3–7 млн ₽. B2B-портал с интеграциями — 6–15 млн ₽. ERP среднего размера — 10–25 млн ₽. Enterprise с микросервисами — от 15 млн ₽ и выше.

Сколько времени занимает разработка?

Простое SPA — 2–3 месяца. MVP-сервис — 3–4 месяца. Личный кабинет — 4–6 месяцев. Средняя CRM — 5–8 месяцев. B2B-портал — 7–10 месяцев. ERP — 9–14 месяцев. Enterprise — 12–24 месяца. Сроки сильно зависят от готовности заказчика и скорости согласований.

React или Vue — что выбрать?

Для большинства бизнес-задач подходят оба. React — если проект крупный, нужна большая команда и рядом будет мобильное приложение на React Native. Vue — если команда небольшая, важна скорость старта и простота обучения. Angular уместен в корпоративной среде с командой 10+ фронтов. Для SEO-зависимых проектов — Next.js.

Нужен ли отдельный backend?

Почти всегда — да. Фронтенд не должен обращаться напрямую в базу, это и уязвимость, и архитектурная ошибка. Исключения: чисто-контентные сайты на headless CMS, маленькие инструменты на Firebase/Supabase. Для любого продукта с ролями, платежами, интеграциями — полноценный бэкенд.

Что такое PWA и когда его выбирать?

PWA (Progressive Web App) — веб-приложение, которое ставится на экран телефона, работает офлайн, шлёт push-уведомления. Подходит, когда нужно «почти нативное» ощущение без двух отдельных приложений под iOS и Android и без App Store. Минус: Apple ограничивает часть возможностей на iOS. Подробнее о PWA.

Можно ли обойтись без дизайнера?

Для внутреннего инструмента из 5 экранов, которым пользуются 10 сотрудников, — да, хватит шаблона Bootstrap / Ant Design. Для продукта с реальными пользователями и коммерческими задачами — нет: шаблонный UI бьёт по конверсии, по доверию, по восприятию бренда. Отдельный дизайнер стоит дешевле, чем переделка всего фронта через полгода.

Как тестировать веб-приложение?

Параллельно с разработкой, а не в конце. Минимум: unit-тесты на критичную логику, интеграционные на API, e2e на ключевые сценарии. Перед релизом — регрессионное, нагрузочное, security-тестирование. Покрытие 60–80% критичных сценариев — разумная цель.

Какую базу данных выбрать?

Для 90% веб-приложений — PostgreSQL + Redis. MongoDB — если структура данных сильно меняется. ClickHouse — если у вас аналитика миллиардов строк. Elasticsearch — если нужен полнотекстовый поиск и фасетные фильтры. Начинайте с простого, добавляйте по мере роста.

Можно ли перенести веб-приложение в мобильное?

Два пути. PWA — бесплатно «устанавливаем» веб как приложение на экран телефона, ограничения есть. Нативная обёртка — пакуем веб в WebView и публикуем в сторах. Для серьёзного мобильного продукта обычно лучше отдельная нативная или Flutter-разработка, потому что веб не даст полного доступа к железу. Подробнее — Как из сайта сделать приложение.

Что такое SPA и когда оно подходит?

SPA (Single Page Application) — приложение, которое загружается один раз, а дальше обновляет содержимое без перезагрузки страницы. Подходит для инструментов, где важна скорость переходов и «нативное» ощущение (CRM, рабочие панели, дашборды). Не подходит, когда критичен SEO без дополнительных ухищрений (тогда — Next.js с SSR).

Чем Surf отличается от других подрядчиков?

Мы специализируемся на сложных веб-приложениях и B2B-порталах, а не на корпоративных сайтах. Внутри есть команды под React, Vue, Next.js (фронт) и Node.js, Python, Kotlin, Go (бэк) — это редкость, обычно студии заточены под один стек. Плюс собственная мобильная разработка (Flutter и нативная), поэтому можем вести продукт на всех платформах в единой архитектуре. Сравнение с другими студиями.

Читать дальше

• Рейтинг компаний по веб-разработке 2026
• PWA: когда выбирать и что это даёт
• Разработка личного кабинета под ключ
• Как из сайта сделать мобильное приложение