Веб-сайт и веб-приложение: в чём разница

Всё сводится к одному вопросу: пользователь потребляет контент или взаимодействует с системой. Сайт — это витрина. Его задача — показать: рассказать о компании, опубликовать статьи, вывести каталог, дать контакты. Пользователь читает и смотрит, максимум — оставляет заявку через форму. Его действия не меняют состояние системы: вы прочитали статью — для следующего читателя ничего не изменилось.

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

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

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

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

Именно на стыке рождается большинство вопросов. Несколько частых случаев, которые сбивают с толку.

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

Интернет-магазин. Формально его все зовут сайтом, по сути это веб-приложение: каталог, корзина, оплата, аккаунты, статусы заказов, интеграции со складом и доставкой — это логика и работа с данными, а не просто страницы.

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

Headless и Telegram mini-app. Контент может отдаваться через headless-CMS, а интерфейс жить отдельным приложением; сценарии всё чаще запускают внутри Telegram как mini-app. Это уже не «сайт против приложения», а варианты того, где и как показать продукт, — но под капотом всё равно либо контент, либо логика с данными, и вопрос сложности решается так же.

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

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

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

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

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

Каждый пласт — это аналитика, разработка и проверка, поэтому сроки измеряются не днями, а месяцами.

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

Как именно устроена разработка веб-приложения — из каких слоёв состоит, какой стек и где хостить с учётом 152-ФЗ — вынесено в отдельную статью; здесь важно понимать, что за одинаковой на вид «страницей в браузере» может стоять и работа на неделю, и работа на полгода.

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

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

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

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

Code Pilots работает именно на стороне приложений: сложные веб-продукты с бизнес-логикой, интеграциями и нагрузкой, силами senior-команды на Symfony и Vue. Если вы не уверены, по какую сторону границы ваша задача, это как раз тот вопрос, который стоит прояснить до старта, а не после.

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

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

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

Code Pilots помогает определить, что нужно под вашу цель, и берёт на себя сложную часть — веб-приложения с бизнес-логикой, интеграциями и нагрузкой на Symfony и Vue. Расскажите, что должен уметь ваш продукт, — подскажем, сайт это или приложение, и во что это выльется по объёму.