Заказчик приходит в студию и говорит: «Нужен сайт». Через две встречи выясняется, что нужен личный кабинет, расчёт заказа по десятку параметров, интеграция с 1С и онлайн-оплата. Формально это уже не сайт, а веб-приложение. И наоборот: иногда под словом «сервис» скрывается обычный лендинг с формой заявки. Путаница в терминах стоит денег — она ведёт к неверной оценке сроков, бюджета и команды. Разберёмся, где проходит граница и как определить, что именно нужно вашему бизнесу.
Коротко: в чём суть разницы
Сайт в первую очередь рассказывает и показывает. Веб-приложение — делает работу за пользователя. Сайт отвечает на вопрос «что здесь есть и почему мне это интересно», приложение — на вопрос «как мне выполнить задачу прямо сейчас».
Это не строгая техническая классификация, а скорее спектр. На одном его конце — визитка на пять страниц, на другом — CRM в браузере. Большинство реальных проектов где-то посередине, и задача — понять, к какому полюсу вы ближе.
Что такое сайт
Сайт — это набор страниц с контентом: текстами, изображениями, видео. Пользователь переходит по ссылкам, читает, смотрит, оставляет заявку. Основное взаимодействие — просмотр.
Типичные примеры:
- корпоративный сайт с описанием услуг и команды;
- лендинг под конкретную рекламную кампанию;
- блог или медиа с редакционными материалами;
- каталог товаров без оформления заказа на сайте.
Технически такие проекты чаще всего собирают на CMS — WordPress, Tilda, «1С-Битрикс». Контент обновляется редактором, а не программистом. Основные метрики — трафик, глубина просмотра, количество заявок.
Что такое веб-приложение
Веб-приложение — программа, которая работает в браузере и решает конкретную задачу пользователя. Здесь важна не страница, а функция: создать заказ, рассчитать смету, согласовать документ, провести платёж.
Примеры:
- личный кабинет клиента банка или интернет-магазина;
- система бронирования с выбором даты, номера и оплатой;
- сервис доставки еды с корзиной, статусами и трекингом курьера;
- внутренний портал для сотрудников: заявки, отчётность, согласования.
Пользователь не «читает» такое приложение, а работает в нём: вводит данные, получает результат, видит изменение состояния. За этим стоит серверная логика, база данных, часто — внешние API и интеграции.
Ключевые отличия
Логика работы
Сайт статичен по своей природе: страницы выглядят одинаково для всех, отличаются лишь роли и права доступа. Приложение динамично — интерфейс меняется в зависимости от действий пользователя, его данных и статуса задачи.
Данные и состояние
Сайту достаточно хранить контент. Приложению нужно хранить и постоянно обновлять состояние: корзину, историю заказов, баланс, прогресс задачи. Отсюда — база данных, разграничение прав, логирование действий, работа с персональными данными.
Интерфейс и навигация
На сайте навигация строится вокруг страниц и меню. В приложении — вокруг сценариев: шаг 1, шаг 2, шаг 3. Если пользователь не понимает, что делать дальше, страдает не «читабельность», а выполнение задачи. Поэтому UX-проектирование здесь занимает куда больше времени.
Технологии и стоимость
Сайт чаще собирают на готовой платформе: быстро и предсказуемо по бюджету. Приложение обычно пишут на фреймворке — React, Vue, Angular во фронтенде и Node.js, Python, PHP на бэкенде. Это дольше, дороже и требует постоянной поддержки: обновления, нагрузка, безопасность.
Гибридные случаи: где граница размывается
Интернет-магазин — классический пример гибрида. Каталог и карточки товаров — это сайт. Корзина, оформление заказа, личный кабинет с историей покупок — уже приложение. То же самое с сервисами записи: страница с описанием услуг — сайт, а модуль выбора времени и оплаты — приложение.
На практике вопрос звучит не «сайт или приложение», а какую часть задачи закрывать какой частью системы. Иногда разумно начать с сайта и заявок в почте, а кабинет прикрутить позже, когда объём заказов это оправдает.
Что выбрать бизнесу: практический алгоритм
Ответьте на четыре вопроса.
- Что делает пользователь? Читает и выбирает — сайт. Вводит данные и получает результат — приложение.
- Нужен ли личный кабинет с разными правами? Если да, вы уже в зоне приложения.
- Есть ли сложная логика? Расчёты, фильтры по десяткам параметров, статусы, автоматизация — это приложение.
- Как часто всё будет меняться? Если правила и сценарии будут переписывать каждый месяц, нужна архитектура, которую не стыдно развивать, а не набор страниц.
И главное: посчитайте, сколько денег и времени принесёт функция. Если кабинет окупается за счёт повторных продаж — вкладываться стоит. Если заявки и так обрабатываются вручную без потерь — возможно, вы переплатите за сложность.
Типичные ошибки при выборе
- Заказывать приложение там, где хватит сайта. Получается дорогая система, которой никто не пользуется.
- Пытаться собрать приложение на CMS. Плагины конфликтуют, логика обрастает костылями, поддержка превращается в постоянный ремонт.
- Экономить на проектировании. Пропущенный этап сценариев приводит к переделке интерфейса после запуска.
- Не закладывать поддержку. Приложение — это живой продукт: обновления, нагрузка, безопасность, доработки.
Что в итоге
Сайт — это про присутствие и коммуникацию. Веб-приложение — про функции и автоматизацию. Большинство бизнесов нуждаются в комбинации: понятная публичная часть плюс рабочие сценарии для клиентов или сотрудников.
Правильный старт — не выбор технологии, а описание задач: что делает пользователь, что должно произойти после его действия и как вы поймёте, что это сработало. Когда сценарии описаны на бумаге, тип проекта определяется сам собой — и бюджет с ним становится предсказуемым.
Спасибо, что разложили по полочкам. Я после статьи пересмотрела наш корпоративный сайт и поняла, что часть функций — история обращений, статусы заявок — уже тянет на веб-приложение. Теперь думаю, не пора ли выносить это в отдельный кабинет.
Я запутался в одном моменте: каталог с фильтрами и сортировкой, но без корзины и оплаты — это ещё сайт или уже приложение? По статье выходит, что ближе к сайту, но динамическая выдача и запросы к базе как-то смущают. Как вы обычно проводите границу в таких случаях?
Хороший вопрос. Я бы смотрел не на фильтры, а на то, ради чего пользователь пришёл: если он только выбирает товар и оставляет заявку, это сайт с динамическими элементами. Если система должна помнить его данные, считать заказ, менять статусы и проводить оплату — это уже веб-приложение. В спорных случаях я предлагаю считать количество пользовательских сценариев, которые нужно реализовать.
Не совсем согласна. У нас каталог без личного кабинета, но с расчётом доставки через API и выбором пункта выдачи. Формально это не приложение, но и обычным сайтом назвать уже язык не поворачивается. Мне кажется, интеграции тоже сильно меняют сущность проекта.
У нас была обратная история: заказывали «лендинг» под рекламу, а в процессе выяснилось, что нужен калькулятор с личным кабинетом и интеграцией с CRM. В итоге сроки выросли почти вдвое. Я теперь на старте прошу описать не страницы, а задачи пользователя — так сразу видно, сайт это или приложение.
Вот поэтому я перестал объяснять клиентам разницу через технологии. Говорю проще: «сайт рассказывает, приложение делает». После этого брифы стали точнее.