Сайт в первую очередь объясняет, кто вы, что предлагаете и как с вами связаться. Веб-приложение помогает пользователю выполнить действие внутри системы: создать заказ, загрузить документ, рассчитать стоимость, вести учёт, согласовать заявку или работать с личными данными. Есть промежуточные форматы — каталог с корзиной, калькулятор, форма с кабинетом, портал — поэтому выбирать нужно по сценарию и данным.
Если посетитель читает и оставляет заявку, часто достаточно сайта. Если он возвращается, входит в аккаунт, меняет записи и ожидает персональный результат, перед вами уже веб-приложение или сайт с приложенческим модулем.
Главная ошибка — выбирать по внешнему виду
Гипотетическая ситуация: компания заказывает современный сайт, а затем добавляет роли менеджеров, историю заказов, документы, уведомления и расчёты для каждого клиента. Визуально это всё ещё сайт. По логике — уже система.
Если не назвать разницу на старте, команда оценивает публичные страницы, а позже обнаруживает базу данных, авторизацию, права доступа, серверную логику, интеграции и тестирование. Это не обязательно плохо, но это другой объём и другие риски. Правильный первый вопрос: что должен сделать пользователь после того, как прочитает страницу?
Сайт: когда важны содержание и конверсия
Сайт подходит, если задача — представить компанию, услугу или продукт, объяснить ценность, ответить на вопросы и привести человека к контакту. В нём могут быть формы, каталог, блог, SEO-страницы, аналитика, CRM-интеграция и небольшой калькулятор. Наличие формы само по себе не превращает сайт в полноценное веб-приложение.
Для такого проекта важны структура контента, скорость, мобильная версия, доступность, поисковая разметка, путь к заявке и управляемость страниц. Если сайт собирается на конструкторе, заранее уточняют ограничения экспорта, форм, CMS, локализации, ролей и интеграций.
Официальная документация Tilda указывает, что экспорт доступен на определённом тарифе и имеет ограничения для CRM, Members, каталога и форм. Webflow отдельно предупреждает, что при экспорте не переносятся CMS, User Accounts, Ecommerce и часть функциональности форм. Это не аргумент за или против платформы, а повод проверить требования до выбора.
Веб-приложение: когда пользователь работает с данными
Веб-приложение начинается там, где результат зависит от пользователя, роли, записи или состояния процесса. Примеры: личный кабинет, B2B-портал, рабочее место оператора, сложный калькулятор, система заявок или сервис с подпиской.
- Какие сущности хранятся и кто ими владеет?
- Какие роли видят и изменяют данные?
- Что происходит после каждого действия?
- Как устроены уведомления, повторные попытки и ошибки?
- Какие данные приходят из внешних систем?
- Как пользователь возвращается к незавершённой работе?
Чем больше ответов, тем меньше проект похож на набор страниц и тем больше похож на продуктовую систему. Для безопасности веб-приложения OWASP ASVS предлагает основу проверяемых требований, а не декларацию «данные защищены».
Пять признаков, что нужен не только сайт
| Признак | Что это означает | Что уточнить |
|---|---|---|
| Личный вход | результат зависит от пользователя | роли и сессии |
| История операций | важны прошлые состояния | журнал и хранение |
| Персональные данные | страницы показывают разные данные | доступ и минимизация |
| Сложный расчёт | результат зависит от условий | правила и тесты |
| Рабочий процесс | записи проходят статусы | ответственные и исключения |
Один признак ещё не требует полноценной платформы: форма с отправкой в CRM может оставаться частью сайта. Но несколько признаков сразу — сигнал провести короткий discovery, а не прятать будущую систему в формулировку «пара страниц».
Как выбрать формат разработки
Опишите путь пользователя
Запишите действия от первого визита до результата. «Открыл страницу — отправил контакты» и «вошёл — выбрал заказ — загрузил документ — получил статус» требуют разных архитектур.
Отделите публичную часть от рабочей
У одного проекта могут быть маркетинговый сайт и веб-приложение за авторизацией. Их не обязательно строить на одном инструменте. Такое разделение часто упрощает контент, права и развитие продукта.
Проверьте ограничения платформы
Спросите, где хранятся данные, можно ли подключить интеграцию, экспортировать контент, управлять ролями и перенести проект. Обещание «код выгрузим потом» недостаточно: у каждой платформы есть функции, которые при экспорте не работают или требуют внешнего сервиса.
Соберите критерии приёмки
Для сайта это мобильные страницы, формы, аналитика, скорость и поисковая разметка. Для приложения добавятся права, ошибки, повторные операции, история, резервирование и пограничные состояния. Критерии должны описывать результат, а не только наличие экранов.
Оцените не только запуск
Нужно понять, кто будет обновлять контент, поддерживать интеграции, отвечать за доступы, выпускать изменения и разбирать инциденты. Сайт и веб-приложение отличаются и последующей ответственностью.
Где конструктор полезен, а где становится ограничением
Конструктор удобен, когда нужен быстрый публичный слой, стандартная структура страниц и понятный набор интеграций. Заказная разработка оправдана, когда логика, данные, роли или интеграции являются главным продуктом, а не дополнением к презентации.
Не сравнивайте подходы только по цене первой версии. Сравнивайте стоимость изменения: добавить страницу и добавить новый тип роли — разные операции. Так же различаются переносимость данных, контроль над кодом, зависимость от тарифа и возможность тестировать критичные правила.
Как Paladin Engineering может помочь
Paladin Engineering может провести discovery и разложить проект на публичный сайт, закрытую рабочую часть и интеграции. На выходе заказчик получает карту сценариев, список сущностей и ролей, прототип ключевого пути, технические ограничения и понятный объём первой версии. Если формат уже выбран, команда может реализовать сайт, веб-сервис или связку из двух частей.
Чтобы обсудить границы проекта и получить оценку первой версии, полезно принести на первую встречу ссылку на текущий сайт, описание главного действия пользователя и пример результата, который должен появиться после этого действия. Этого достаточно, чтобы не спорить о технологиях в отрыве от задачи.
Частые вопросы
Интернет-магазин — это сайт или веб-приложение?
Зависит от логики. Простая витрина с внешней оплатой может быть сайтом с каталогом, а персональные заказы, аккаунты, остатки, статусы и роли продавцов превращают проект в приложение или платформу.
Можно ли начать с сайта, а приложение добавить позже?
Да, если заранее определить модель данных, домены, интеграции и границу между публичной и закрытой частью. Иначе приложение придётся собирать вокруг ограничений первой версии.
Нужен ли личный кабинет для каждой услуги?
Нет. Кабинет оправдан, когда пользователь возвращается к данным, документам, заказам или статусам. Для разовой заявки достаточно формы и понятного канала ответа.
Достаточно ли прототипа страниц?
Нет. Нужны состояния, роли, ошибки, пустые списки, загрузка, повторное действие и правила переходов. Иначе прототип проверит только идеальный маршрут.
Как сравнивать предложения подрядчиков?
Сопоставляйте сценарии, данные, интеграции, ограничения платформы, критерии приёмки и поддержку после релиза. Чем точнее граница сайта и приложения, тем честнее сравнение.
Что принести на discovery?
Ссылку на текущий сайт, описание главного действия пользователя и пример результата. Этого достаточно для первого разговора о границах продукта.
Итог
Сайт отвечает на вопрос «кто вы и что предлагаете», веб-приложение — «что пользователь может сделать с данными». Граница определяется состояниями, ролями, логикой и ответственностью за результат. Опишите путь пользователя, отделите публичную часть от рабочей и проверьте ограничения платформы до согласования бюджета.
Комментарии