Сначала сформулируйте повторяющуюся задачу
Просьба «сделайте приложение, как у конкурента» ещё не объясняет, зачем его установят. Опишите действие, которое клиент выполняет сейчас: повторяет заказ, получает задание, проверяет статус, записывается на обслуживание. Затем выясните, как часто это происходит и что мешает пройти путь существующим способом. Ответы лучше искать в разговорах с клиентами и сотрудниками, а не в собственных ожиданиях. Условный пример: поставщик расходных материалов хочет облегчить повторный заказ для постоянных покупателей. Здесь есть предмет для исследования. Если же покупатель один раз выбирает монтажную компанию и отправляет запрос, установка отдельного приложения требует дополнительного обоснования. Это примеры принятия решения, а не описания выполненных проектов.
Проверьте, достаточно ли хорошего мобильного сайта
Для первичного знакомства с компанией подготовьте маршрут: открыть ссылку, понять предложение, посмотреть условия, связаться. Проверьте его на телефонах клиентов. Если проблема в непонятном тексте, неудобной форме или неактуальных контактах, перенос этих же элементов в приложение не решит исходную задачу. Адаптивный сайт разумно рассматривать как самостоятельный продукт, а не временную заглушку. Составьте критерии приёмки: текст читается без увеличения, важные кнопки доступны, форма сохраняет введённое при ошибке, подтверждение объясняет дальнейшие действия. Для аудитории Узбекистана проверьте русскую и узбекскую версии по одному сценарию. Язык меню должен соответствовать языку содержания и ответа менеджера.
Разберите функции телефона по отдельности
Вместо общего требования «нужны возможности смартфона» перечислите конкретные действия: сфотографировать документ, считать код, показать маршрут, сохранить черновик, отправить напоминание. Для каждого запишите, зачем оно пользователю, что произойдёт при отказе в разрешении и можно ли завершить задачу иначе. Один сложный пункт не обязательно определяет весь продукт. Попросите разработчика проверить наиболее рискованный сценарий отдельным прототипом на целевых устройствах. Укажите условия проверки: слабая связь, повторный запуск, отказ в доступе, смена языка. Такая проверка даёт основание для выбора технологии. Демонстрация красивого экрана без работающей ключевой функции этого основания не даёт.
Рассмотрите PWA как отдельный вариант
В руководстве web.dev PWA описывается как веб-приложение с возможностями установки и работы без сети; доступность функций зависит от платформы. Источник: «Progressive Web Apps» в списке ниже. Из этого не следует, что любой сайт автоматически получает все такие возможности. Для вашего проекта составьте собственный список обязательного поведения. Например, в условном каталоге можно обсудить сохранение выбранных позиций при потере связи, но подтверждение актуальной доступности оставить до подключения. Решите, как пользователь увидит устаревшие данные и статус отправки. Сравнивать PWA с приложением полезно по этому конкретному сценарию, включая ограничения, а не только по наличию значка на экране.
Учтите путь до установки и первого результата
Запишите весь первый визит будущего пользователя: откуда он узнает о продукте, что поймёт до установки, когда создаст учётную запись и какое полезное действие выполнит. Обсудите, действительно ли регистрация нужна до знакомства с предложением. Если менеджеру придётся долго объяснять пользу, сначала уточните саму пользу. Apple в пункте 4.2 правил проверки требует, чтобы приложение предлагало больше, чем переупакованный сайт. Источник: App Review Guidelines. Поэтому обещать принятие простой оболочки сайта заранее нельзя. В план проекта включите подготовку материалов для публикации, проверку требований выбранного канала распространения и ответственного за возможные уточнения.
Считайте работу после первого выпуска
При сравнении вариантов попросите описать не только разработку экранов. Нужны управление содержанием, серверная часть при её наличии, проверка изменений, восстановление после сбоев, работа с обращениями пользователей и передача доступов. Для каждого варианта выясните, что уже есть у бизнеса и что придётся создать. Отдельно назначьте владельца продукта: кто решает, какие функции действительно нужны, утверждает переводы и отвечает на сообщения клиентов. Если такого человека нет, приложение рискует остаться без актуального содержания. Сравнивайте предложения по одинаковому набору сценариев и обязанностей. Формулировка «дешевле в разработке» без границ поддержки не показывает полную картину будущей работы.
Зафиксируйте критерий перехода к приложению
Не обязательно принимать решение навсегда. Можно начать с сайта и заранее определить, какие наблюдения станут поводом вернуться к приложению: устойчивые повторные задачи, конкретные неудобства пользователей, подтверждённая потребность в проверенных возможностях устройства. Не назначайте универсальный порог установок или посещений: он должен иметь смысл именно для вашего процесса. Для первого разговора с разработчиком подготовьте описание аудитории, основного действия, частоты использования, целевых устройств и доступной поддержки. Попросите сравнить два осуществимых варианта и назвать неизвестные условия. Хорошее решение объясняет, какую проблему оно снимает сейчас, как вы проверите результат и что потребуется для следующего шага.
Вопросы заказчиков
Можно ли сначала сделать сайт, а приложение позже?
Да. Заранее обсудите повторное использование содержания и серверных функций, но не усложняйте первую версию ради неподтверждённых планов.
Приложение само по себе увеличит продажи?
Такой гарантии нет. Нужны полезный сценарий, понятное предложение, привлечение пользователей и работа бизнеса после обращения.
PWA полностью заменяет приложение?
Это зависит от необходимых сценариев и устройств. Проверьте обязательные функции на прототипе, прежде чем выбирать вариант.