Когда клиент говорит «нам нужно приложение», первым делом звучит вопрос: нативное или веб? Сейчас мы разрабатываем фитнес-сервис для Алматы, где спортсмены записываются на тренировки, а тренеры ведут расписание. Мы выбрали PWA — веб-приложение, которое устанавливается на телефон, — но спроектировали его так, чтобы через год мобильные разработчики могли написать нативное приложение, не переделывая серверную часть. На этом примере покажем, как принимаются такие решения.
Задача
Сервис объединяет спортивные и развлекательные события: бег, йогу, кроссфит, танцы, горы и ещё полтора десятка категорий. Пользователь записывается на тренировку, отмечается по QR-коду, после занятия оценивает себя и тренера. Из оценок складываются ежемесячный и ежегодный рейтинги, за активность начисляются бонусы, которые можно обменять на награды. Есть друзья с рекомендациями «возможно, вы знакомы», подписки и уведомления.
В системе две роли — спортсмен и тренер — с общей авторизацией. Старт в Алматы, дальше Астана. Интерфейс на трёх языках: казахском, русском и английском.
Шаг 1. Почему PWA, а не сразу нативное приложение
Сервисом пользуются только с телефона: записаться на пробежку, показать QR-код на входе, поставить оценку после занятия. Поэтому мы сразу отказались от десктопной версии и проектируем интерфейс только под мобильный экран.
PWA закрывает основные потребности приложения:
- устанавливается из браузера на главный экран и открывается как обычное приложение;
- поддерживает push-уведомления, в том числе на iPhone, если приложение добавлено на главный экран;
- обновляется сразу у всех пользователей, без проверки в магазинах приложений;
- одна кодовая база вместо двух — значит, один бюджет и быстрый запуск.
Мы рассматривали и промежуточный вариант — упаковать веб-приложение в нативную оболочку. От него отказались: он добавляет ещё один слой, который нужно поддерживать, но не даёт того, чего не умеет PWA на старте. Нативное приложение имеет смысл делать полноценно и отдельно, когда сервис наберёт аудиторию.
Шаг 2. API с первого дня
Главное решение в проекте — вся бизнес-логика живёт на сервере, а не в экранах приложения. Запись на тренировку, подсчёт опозданий, рейтинги, начисление бонусов, оплата подписки — всё это отдельный слой, к которому обращаются два интерфейса: PWA на Livewire и REST API для будущего мобильного приложения.
Когда придут мобильные разработчики, им не придётся разбираться в веб-интерфейсе и дублировать правила. Они получат готовое API с описанием каждого запроса и ответа. Для этого мы написали отдельное техническое задание на API: контракты эндпоинтов, форматы данных и ошибок, а также спецификацию панели администратора.
Стек: Laravel 13, Livewire 4 и Tailwind CSS 4 для приложения, Filament 5 для панели администратора. Через админку оператор управляет пользователями, событиями, категориями, городами, бонусами и рассылками.
Шаг 3. ТЗ из макетов
Заказчик пришёл с детально продуманными прототипами: 11 наборов экранов с пояснениями к каждому блоку. Мы собрали их в единое ТЗ на 23 страницы и вставили в него 33 экрана как иллюстрации, чтобы каждое требование было привязано к конкретному месту в интерфейсе.
При разборе прототипов накопилось 13 открытых вопросов. Все мы закрыли до начала разработки. Вот примеры правил, которые должны быть описаны точно, иначе их реализуют по-разному:
- если участник отметился после старта тренировки, он не может поставить себе оценку выше трёх звёзд;
- если за месяц опоздания по одной категории превысили 15 минут, система закрывает доступ к этой категории на одно занятие;
- если участник отказался от занятого места, он теряет баллы рейтинга;
- тренер завершает тренировку, удерживая кнопку три секунды, — это защищает от случайного нажатия.
Такие правила — ещё один аргумент за логику на сервере. Штраф за опоздание должен работать одинаково в PWA и в нативном приложении, и описан он должен быть в одном месте.
Шаг 4. Несколько городов и языков сразу
Первый город — Алматы, но Астана уже в планах. Поэтому город в системе — это отдельная сущность, а не строка текста: пользователь выбирает его из списка, и от города зависит расписание. Запуск в новом городе — это новая запись в админке, а не доработка.
То же с языками. Три языка заложены в структуру данных с самого начала. Добавить язык в готовое приложение намного дороже, чем предусмотреть его в проекте.
Шаг 5. Оплата, привычная в Казахстане
Подписки продаются прямо в приложении, поэтому мы подключаем Kaspi Pay и FreedomPay. Для казахстанского пользователя оплата через Kaspi — ожидаемый вариант по умолчанию.
Отдельно отметили на будущее: при переходе на нативное приложение нужно будет проверить правила App Store и Google Play для оплаты подписок. Это вопрос не кода, а политики магазинов, и лучше знать о нём заранее.
Шаг 6. Несколько вариантов вместо одной цены
Мы подготовили заказчику несколько коммерческих предложений: полное PWA-приложение с админкой; только API и админку — если интерфейс будет делать другая команда; нативное приложение на Flutter как отдельный этап. Заказчик видит, сколько стоит каждый путь, и может двигаться по шагам.
Работу по договору разбили на 10 этапов: дизайн, ТЗ, вёрстка, базовая архитектура, кабинет спортсмена, кабинет тренера, панель администратора, платёжная система, push-уведомления и запуск на хостинге. Кабинеты мы сознательно сделали крупными этапами со списком функций внутри, а не десятками мелких пунктов: так заказчику проще принимать работу, а нам — сдавать её законченными частями. О сдаче каждого этапа сообщаем в WhatsApp — это основной канал связи с заказчиком.
PWA или нативное приложение: когда что выбирать
- PWA подходит, если нужно быстро запуститься, проверить идею и не тратить бюджет на две платформы сразу.
- Нативное приложение нужно, когда важны глубокая работа с устройством, присутствие в магазинах приложений или сложные офлайн-сценарии.
- Лучший вариант часто — начать с PWA, но сразу строить сервер как API. Тогда нативное приложение станет новым интерфейсом, а не новым проектом.
Что из этого стоит взять себе
- Думайте о следующей версии продукта уже сейчас: API с первого дня стоит недорого, а переделка сервера потом — дорого.
- Описывайте бизнес-правила в ТЗ цифрами: «15 минут», «три звезды», «три секунды».
- Закладывайте города и языки в структуру данных до запуска, даже если на старте они не нужны.
Как мы ведём сложные проекты от ТЗ до MVP, мы уже рассказывали на примере платформы для онлайн-арбитража. Если вы задумали мобильный сервис или приложение с личными кабинетами — расскажите нам о нём, и мы поможем выбрать подход, который подойдёт вашему бюджету и планам.
