Сначала опишите сценарии
Укажите, где человек работает, как часто открывает сервис и какие функции телефона нужны. Просмотреть заказ, добавить комментарий и провести сложную операцию без связи — разные требования.
Составьте список устройств и браузеров аудитории. Проверяйте критичные возможности на них до утверждения архитектуры, а не после готового дизайна.
Когда рассмотреть PWA
PWA подходит для сервиса, базовые действия которого доступны в веб-интерфейсе. Пользователь может начать по ссылке; установка на устройство и некоторые дополнительные возможности зависят от браузера.
Такой подход стоит проверить для кабинета клиента, рабочего журнала или системы с формами и расписанием. Один адрес также удобно использовать в письмах, справке и рекламных переходах.
Офлайн — отдельная часть проекта
Наличие service worker не означает, что весь продукт работает без сети. Нужно выбрать, какие данные хранить локально, как обозначать их актуальность и что делать с изменениями после восстановления связи.
Например, показать ранее загруженный заказ проще, чем разрешить нескольким сотрудникам менять его без интернета. Во втором случае нужны правила разрешения конфликтов и защита локальных данных.
Когда изучать мобильную разработку отдельно
Если ключевой сценарий требует возможностей устройства или фоновой работы, которых нет в целевых браузерах, сравните нативный и кроссплатформенный подходы. Проверка небольшого технического прототипа поможет принять решение.
Публикация в магазине приложений, правила обновления и сопровождение платформ также включаются в проект. Не следует считать их частью разработки PWA по умолчанию.
Критерии приёмки вместо спора о технологии
Зафиксируйте конкретные действия: войти, открыть данные, выполнить операцию, увидеть ошибку связи и продолжить работу. Проверьте уведомления с разрешением и без него. Технология подходит, если эти сценарии работают в согласованном окружении.