Веб-приложение или сайт: чем отличается разработка и что выбрать бизнесу

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

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

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

Веб-приложение держит роли, сценарии и серверную логику. Клиент, менеджер и администратор видят разное. Заявка идёт по статусам. Есть очереди, уведомления, иногда обмен в реальном времени. Этим продуктом работают, а не только знакомятся с компанией.

Один адрес в браузере ничего не решает. JavaScript на витрине не превращает её в приложение. Кабинет на «обычных» страницах с проверкой прав на сервере — уже приложение. Смотрите на функции, а не на «есть ли скрипты».

Пример из ниши студии. Витрина услуг с портфолио и формой — сайт. Кабинет заявок: клиент видит обращения, менеджер меняет статус, система пишет в CRM — веб-приложение. Макет может совпадать. Набор сценариев — нет.

Сайт показывают гостю. Приложением пользуются каждый день: критерий не макет, а роли, сценарии и серверная логика.

Мнение. Если человек заходит раз и оставляет телефон — берите сайт. Если одни и те же люди каждый день ведут статусы — закладывайте разработку приложения.

Матрица функций: какой продукт закрывает задачу

Сверяйте задачу с функциями, а не с модным названием. Одни критерии годятся и лендингу, и магазину, и кабинету: каталог, корзина, роли, realtime, офлайн, 1С и CRM, оплата, карты. Где в строке сплошные «нет» и «частично», одностраничника уже мало.

Лендингу и визитке хватает оффера, формы и аналитики. Корпоративному сайту — разделов, новостей, иногда нескольких языков, без тяжёлой логики статусов. Интернет-магазину нужны каталог, корзина и оплата, часто — выгрузка в 1С и CRM. Пока покупатель оформляет заказ как гость, это ещё сайт с витриной. Когда появляются роли закупщика, менеджера и согласование счёта — это уже приложение вокруг магазина.

Веб-приложение держит роли, согласования, внутренние процессы. Интеграции здесь ядро продукта, а не плагин «на потом». Realtime и офлайн имеют смысл, только если без них ломается рабочий день, а не «для солидности».

Если процесс живёт в таблице и мессенджере, а сайт только «красиво лежит» — тип продукта выбран мимо задачи. Сначала допишите сценарии, потом выбирайте сборку.

MPA, SPA, SSR и PWA: SEO, скорость и индексация

Архитектура бьёт по поиску и первой отрисовке сильнее, чем палитра в макете. От выбора MPA, SPA, SSR или PWA зависят Core Web Vitals: LCP, INP и CLS. Пороги этих метрик смотрите на web.dev и меряйте свой URL, а не чужой «средний балл».

MPA отдаёт отдельные страницы готовым HTML. Роботу Яндекса такой обход привычен: каждая посадочная — свой документ. SPA — частая схема кабинета: интерфейс живёт в браузере, сервер отдаёт данные. Для витрины в поиске это риск: без серверного рендера робот может получить пустую HTML-заглушку. Как Яндекс обходит JavaScript, читайте в справке Вебмастера, а не в пересказах.

SSR улучшает индексацию и первую отрисовку SPA: сервер присылает готовый HTML, интерфейс потом «оживает». Так делают, когда нужны и кабинет, и посадочные в выдаче. SSG собирает HTML заранее — уместно для редко меняющихся страниц. PWA добавляет офлайн-сценарии и установку на домашний экран. Набор возможностей на iOS и Android не совпадает: установка и Web Push зависят от платформы. Версии ОС здесь не фиксируем — сверяйте текущие ограничения в документации Apple и Google.

Факт. SSR улучшает индексацию и первую отрисовку SPA: сервер отдаёт готовый HTML, а не пустую оболочку, которую робот может не исполнить.

Публичные страницы, по которым вы хотите трафик из поиска, отдавайте HTML. Кабинет за авторизацией можно оставить клиентским. Если продажи зависят от органики, SPA без серверного рендера — не ваш случай.

Лендинг, визитка, магазин или приложение

Тип продукта выбирают по цели: лиды, доверие, розница или ежедневная операционка. Способ сборки — конструктор, CMS, кастом — это следующий шаг, его сюда не смешивайте. Адаптив нужен всем типам: это не отдельный «вид сайта» и не замена мобильному приложению.

Лендинг закрывает одну кампанию: оффер, аргументы, форма. Нескольких экранов мало, когда офферов несколько, нужна география офисов или длинное портфолио — тогда это уже не одностраничник. Для оффера и заявок берите одностраничный сайт под оффер и заявки. Визитка и корпоративный сайт держат реквизиты, услуги, портфолио, гео. Им нет дела до ролей внутри заказа.

Интернет-магазин — каталог и оплата. Граница с приложением проходит там, где появляется B2B-кабинет, разные цены по ролям, согласование счёта. Розницу с корзиной закрывает интернет-магазин с каталогом и оплатой. Веб-приложение — продукт, которым сотрудники или клиенты работают ежедневно: статусы, очереди, права, нестандартные связки.

Лиды с одной кампании закрывает лендинг. Витрина услуг и доверие — визитка или корпоративный сайт. Розница с оплатой — интернет-магазин. Личный кабинет, роли, внутренний процесс — веб-приложение.

Локальной компании с коротким оффером лендинга обычно достаточно. Магазин «на вырост под B2B» без описанных ролей почти всегда расползается: сначала делают витрину, потом через боль дописывают кабинет.

Сроки, бюджет и стоимость владения

Счёт за разработку — не вся сумма. TCO включает хостинг, SSL, поддержку и доработки после запуска. Дешевле считать контур целиком: сервер, сертификат, CDN, бэкапы, мониторинг, мелкие правки. Вилки в рублях без расчёта по вашему брифу здесь не ставим: срок и бюджет двигают дизайн, интеграции, роли, контент и приёмка.

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

Хостинг тоже разный. Лендинг живёт на статике или shared. Магазин и приложение — на VPS или в контейнерах, со SSL, бэкапами и наблюдением за сбоями. Ежемесячная поддержка закрывает ошибки, обновления CMS и небольшие доработки. Долю от разработки заранее не назначают: чем чаще меняется логика, тем дороже держать продукт. Сильнее всего счёт меняют интеграции с 1С, CRM и оплатой, кастомные роли, realtime и миграция данных.

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

Конструктор, CMS или кастом: когда сайт перерастает

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

CMS держит контент-модель, страницы и типовой магазин из коробки. Так собирают корпоратив и розницу, в том числе на 1С-Битрикс, если нужна связка с учётом. Плагин превращается в долг, когда им обходят ограничение платформы: два модуля на одну роль, ручные выгрузки, конфликт обновлений. Кастом нужен, когда своя логика, очереди, роли и интеграции не влезают в CMS без борьбы с платформой.

Сигналы миграции. Процесс дублируют в Excel. Менеджеры обходят сайт в мессенджере. Плагины конфликтуют после каждого обновления. Личный кабинет «дописали» поверх витрины и сломали каталог. Тогда наращивать конструктор обычно дороже, чем выделить серверную логику.

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

Кастом нужен не «для солидности», а когда логика не влезает в CMS без борьбы с платформой.

152-ФЗ, cookies, оферта и платежи

Форма заявки и личный кабинет — это обработка персональных данных по 152-ФЗ, а не «просто поля на сайте». До запуска зафиксируйте цели обработки и политику. Для форм и кабинета обычно берут согласие под фактические сценарии: баннер cookies правовое основание не заменяет. Метрика и рекламные пиксели живут отдельно от фразы «мы используем файлы cookie».

Поручение обработчику — хостингу, рассылке, CRM — фиксируют договором, а не галочкой в админке. Уведомление Роскомнадзора и хранение данных в РФ зависят от состава обработки: это не правило «всегда» и не правило «никогда». Студия внедряет формы, хранение и доступы. Юрист заказчика подтверждает формулировки. Обещать, что «юристы закрыты под ключ», нельзя.

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

• Политика обработки персональных данных.
• Согласие под фактические цели, не «на всё сразу».
• Оферта и реквизиты, если есть продажа.
• Проверка, нужно ли уведомление Роскомнадзора.
• Договор с хостингом и другими обработчиками.

Кабинет и оплату не запускаем без этого контура: сначала документы и размещение данных, потом реклама.

Пока роли и интеграции не названы, оценка срока — гадание. Сначала сценарии, потом стек.

Кому что подходит: итоговая рекомендация

Лучшего стека «вообще» нет. Лучший зависит от задачи, бюджета поддержки и того, нужен ли поиск. Сначала сценарии и роли, потом CMS или кастом — иначе бюджет уходит в переделку интерфейса.

Лендинг и визитка закрывают локальный оффер, портфолио, заявки. Корпоративный сайт на CMS — контент и несколько услуг без тяжёлой логики. Интернет-магазин — розница и оплата; B2B-кабинет лучше вынести следующим этапом, а не прятать в плагин. Веб-приложение — роли, статусы, внутренние процессы, нестандартные интеграции.

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

Сначала сценарии и роли, потом CMS или кастом — иначе бюджет уходит в переделку интерфейса.

Опишите, кто что делает за один заход на продукт — по этому списку видно, собирать страницы или кабинет.

Источники

• Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных» — КонсультантПлюс
• Core Web Vitals — web.dev, Google
• Справка Яндекс.Вебмастера — Яндекс
• Progressive web apps — MDN Web Docs