Веб-приложение начинается с действий пользователя, а не с макета главной. Кто входит, что меняет, какие данные видит соседняя роль — это и есть продукт.
В чём проблема
Сайт показывает информацию. Приложение её меняет: заявки, заказы, статусы, файлы, права. Если это смешать с «просто страницами», через полгода каждое новое поле ломает соседний экран.
Так бывает, когда логику кладут в кнопки интерфейса, а база оказывается набором таблиц без связей. Отчёт собирается руками, а два менеджера правят одну запись одновременно.
Как это обычно устроено
Рабочая схема простая:
- интерфейс на React или Next.js, без бизнес-правил внутри компонентов;
- API, которое проверяет роль и отдаёт только нужные поля;
- база, где заказ, клиент и статус — отдельные сущности;
- очередь или фон для писем, файлов и выгрузок, чтобы экран не ждал сеть.
Авторизация — не страница «войти». Это список ролей: клиент, оператор, администратор. У каждой свой набор экранов.
Пример
Сервис заявок на замер. Клиент создаёт заявку и видит статус. Оператор назначает выезд. Руководитель смотрит загрузку по дням. Одно приложение, три интерфейса, одни данные. Письмо «заявка принята» уходит из фона, а не из обработчика кнопки.
Что проверить до разработки
Список экранов, роли, что хранится, что приходит извне (оплата, склад, почта) и что должно работать, если внешний сервис лежит. Без этого оценка — гадание.
Если готовый конструктор закрывает только витрину, а учёт живёт в таблицах, дешевле собрать своё приложение вокруг процесса, чем наращивать плагины.