PWA-приложение или кроссплатформа: новое приложение для ломбарда

Зачем ломбарду собственное мобильное приложение

В России ломбард работает по закону № 196-ФЗ «О ломбардах» и находится под надзором Банка России. Клиент сдаёт вещь в залог, получает займ и залоговый билет, а потом в срок платит проценты или выкупает вещь. Если пропустить срок, вещь после льготного периода может уйти на реализацию.

Раньше почти всё это требовало визита в отделение. Продлить займ, внести проценты, узнать остаток долга. Для сети с базой в 100 тысяч клиентов это тысячи визитов в месяц, очереди и нагрузка на сотрудников.

Приложение переносит самые частые операции в телефон. Филиал остаётся для того, что нельзя сделать удалённо: принять новую вещь и оценить её.

PWA, кроссплатформа или нативная разработка

Мы перевели проект с PWA на кроссплатформу. Выбор между тремя подходами у финансовых сервисов возникает почти всегда, поэтому сведу различия в таблицу.

Что такое PWA и как оно устроено

PWA (Progressive Web App) — сайт, который браузер умеет установить как приложение: с иконкой на экране, отдельным окном без адресной строки и работой при слабой связи. Термин придумали в 2015 году Алекс Расселл и Фрэнсис Берримен из Google.

Технически PWA держится на трёх вещах. Манифест — JSON-файл с названием, иконками и цветами. Service worker — скрипт, который перехватывает запросы, кеширует данные и принимает push. И HTTPS, без которого браузер не включит ни то, ни другое.

Плюс подхода — один код с сайтом и обновление без модерации. Минус — зависимость от браузера: на iPhone возможности PWA долго отставали от Android, а в магазины приложений такой сайт сам не попадает.

Почему кроссплатформенное приложение, а не PWA

Главные причины — push-уведомления и присутствие в магазинах приложений. Оба пункта напрямую влияют на то, вовремя ли клиент платит. Apple добавила поддержку web push для PWA только в iOS 16.4 весной 2023 года, и работает она лишь после установки сайта на экран. Для клиента ломбарда напоминание о сроке платежа критично: пропущенный срок означает риск потерять вещь.

Второй довод — доверие. Финансовое приложение из App Store, Google Play или RuStore выглядит для клиента надёжнее, чем ссылка на сайт.

Flutter или React Native

Оба фреймворка закрывают задачи ломбарда: формы, списки, оплату, push и работу с камерой для фото вещей. Flutter от Google рисует интерфейс сам и даёт одинаковый вид на всех устройствах. React Native от Meta ближе к веб-разработке и удобен, если в компании уже есть React-разработчики. Я бы выбирал по составу команды, а не по бенчмаркам.

Какие функции нужны приложению для залогов

Набор из поста закрывает основной сценарий клиента. Если собирать требования для похожего проекта с нуля, я бы шёл по такому списку.

• Список залогов с суммой долга, датой платежа и статусом каждой вещи.
• Оплата процентов и полное погашение банковской картой или через СБП.
• Частичное погашение, чтобы уменьшить долг и проценты.
• Отсрочка или продление срока без визита в отделение.
• Доступный лимит: новый займ под уже сданную вещь.
• Push за несколько дней до платежа и в день платежа.
• Обучение и сторис для тех, кто впервые пользуется приложением.

Как понять, что приложение работает

Я бы смотрел на четыре метрики. Доля платежей через приложение от всех платежей сети. Число просроченных займов до и после запуска напоминаний. Нагрузка на филиалы в часы пик. Доля клиентов, которые берут повторный займ через доступный лимит.

Скачивания сами по себе мало что значат. Приложение могут установить по просьбе сотрудника в отделении и ни разу не открыть.

Полезно сравнивать не только итоговые цифры, но и поведение по сегментам. Клиенты старшего возраста часто продолжают ходить в отделение, даже если приложение установлено. Для них работают обучение и сторис внутри приложения, о которых я писал выше, и подсказки сотрудников при визите: показать, как оплатить проценты с телефона, занимает пару минут, а следующий визит может уже не понадобиться.

Сроки и состав команды

Кроссплатформенное приложение с таким набором функций обычно делает небольшая команда: аналитик, дизайнер, один-два мобильных разработчика, бэкендер для интеграции с учётной системой ломбарда и тестировщик. Самая долгая часть — не экраны, а интеграция с учётом залогов и платёжным шлюзом, поэтому её стоит начинать первой.

Типичные ошибки в финансовых приложениях

Переносить в приложение всё, что есть в отделении. Клиенту нужны три-четыре действия, остальное мешает.

Прятать оплату за несколько экранов. Если до кнопки «Оплатить» нужно пройти авторизацию, выбор залога, выбор суммы и подтверждение, часть клиентов бросит на полпути и всё равно придёт в отделение.

Забывать о требованиях регулятора. Тексты договоров, расчёт полной стоимости займа и уведомления клиенту должны совпадать с тем, что ломбард выдаёт в отделении, иначе возникнут вопросы при проверке ЦБ.