Веб-приложение — что это и когда оно нужнее сайта

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

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

Сайт показывает, приложение работает

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

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

Практические признаки — если узнали два из них, простого сайта не хватит

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

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

В каких сферах это происходит чаще всего

Вопрос не абстрактный — он повторяется в нескольких сферах:

• Сервисный бизнес (салон, клиника, фитнес-студия) — история визитов, кто когда приходил, автоматические напоминания.
• Недвижимость и аренда — управление объявлениями, список «избранного» у клиента, обновление объявления агентом из своей панели.
• B2B-дистрибьюторы и опт — портал заказов, где у каждого клиента своя цена и свой остаток на складе, заказ без звонка в офис.
• Подписочные и членские продукты — периодическая оплата, управление уровнем доступа, сценарий отмены и продления.

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

В каком порядке двигаться

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

Сначала проверьте готовый блок

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

Зафиксируйте объём письменно, не начинайте вслепую

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

От чего зависит цена

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

Сайт информирует посетителя, приложение делает шаг за него — именно отсюда начинается разница в цене.

Если ваш процесс похож на этот список

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