Банковское приложение за 6 месяцев: как мы это сделали и повторим

Банковское мобильное приложение под ключ — с нуля до релиза в сторах — реально сделать за 6 месяцев, если сразу разделить проект на модули (авторизация, платежи, каталог продуктов) и вести их параллельными командами. Мы прошли этот цикл для регионального банка и готовы повторить его для любого финансового или B2B-проекта с чёткими рамками по безопасности.

📱 с чего начался проект: заявка без ТЗ и дедлайн от совета директоров

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

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

первый месяц: аудит вместо кода

Первые четыре недели мы не написали ни строки продакшен-кода. Собрали техническую сессию с ИТ-директором банка и разобрали, какие данные приложение будет читать из АБС (автоматизированной банковской системы), а какие — из учётной системы на 1С, где велась сверка комиссий и внутренняя бухгалтерия. Выяснилось: часть данных о балансах клиентов дублировалась между двумя системами вручную, раз в сутки, силами одного оператора. Построй мы приложение поверх этой схемы — любая ошибка при ручном переносе превращалась бы в неверный баланс на экране клиента, а это жалоба в ЦБ и репутационный риск, который банк оценивал выше любого срыва срока.

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

Решение по данным — вынести сверку в отдельный сервис с прямым API к 1С, без ручного звена между системами. Здесь пригодился наш опыт интеграции мобильных приложений с 1С — по сути та же задача, что мы решаем для розничных сетей и дистрибьюторов, только с банковским уровнем требований к безопасности передачи данных.

Параллельно провели аудит персональных данных, которые приложение будет хранить и передавать: ФИО, паспортные данные, номер счёта. Требования 152-ФЗ обязывают шифровать такие данные и вести журнал доступа к ним, поэтому архитектуру сразу проектировали с отдельным контуром хранения персональных данных — не достраивали его в последний месяц перед релизом, когда изменения в базовой архитектуре стоят в разы дороже.

разработка по спринтам: график на 6 месяцев

С пятой недели команда разделилась на три потока: авторизация и профиль, платежи и переводы, интеграции с АБС и 1С. Каждый поток вёл отдельный бэклог и сдавал демо раз в две недели — так на пятом месяце мы не собирали приложение впервые целиком, а просто соединяли уже проверенные модули.

почему выбрали нативную разработку, а не кроссплатформенный фреймворк

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

что пошло не так на четвёртом месяце

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

Для банка это было серьёзнее, чем локальный баг интерфейса. Жалобы на медленную работу быстро попадают в отзывы магазинов приложений, а низкий рейтинг на старте — это цифра, которую совет директоров увидит публично ещё до октябрьского отчёта, причём без объяснения контекста.

Решение — вынесли токен-сервис на отдельный инстанс и добавили кэширование баланса на стороне сервера с точечным обновлением по вебхуку из АБС при реальном изменении счёта, а не при каждом открытии приложения. Повторное нагрузочное тестирование через две недели прошло без замечаний, и дата релиза не сдвинулась.

результат через 6 месяцев и во сколько это обошлось

К сентябрю приложение вышло в RuStore и на сайте банка — для клиентов, которые принципиально не ставят приложения из зарубежных магазинов. В нём есть авторизация по биометрии, переводы между своими счетами и в другие банки, оплата услуг ЖКХ и мобильной связи, push-уведомления о списаниях. Данные с балансами синхронизируются с учётной системой на 1С в реальном времени, без ручного звена, которое раньше было источником расхождений.

Разработка мобильного приложения такого масштаба под ключ у нас начинается от 500 000 ₽ — в эту сумму входят отдельные модули авторизации, платежей и API-слой для интеграции с внутренними системами банка. Итоговая смета зависит от количества экранов и глубины интеграции с АБС и 1С; ориентир по стоимости под конкретный проект можно посмотреть на странице тарифов.

🚀 почему мы готовы повторить этот срок для вашего проекта

Шесть месяцев на банковское приложение под ключ — не разовое везение, а результат процесса, который мы теперь используем как отправную точку для новых B2B-проектов: сначала аудит данных и требований безопасности, потом параллельная разработка по модулям, потом нагрузочное тестирование до релиза, а не после жалоб от первых пользователей. У нас уже есть готовые практики интеграции с 1С, шаблон аудита по 152-ФЗ и опыт работы с пиковыми нагрузками — это не нужно придумывать заново под каждого нового клиента.

Модуль интеграции с 1С, который мы построили для этого банка, мы уже адаптировали для двух B2B-заказчиков вне банковской сферы — им не нужно с нуля объяснять нам, как устроена сверка данных между мобильным приложением и учётной системой, мы предлагаем этот блок как готовый кирпич, а не эксперимент.

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

❓ Частые вопросы

Сколько стоит разработка банковского мобильного приложения под ключ?

Разработка мобильного приложения такого масштаба у нас начинается от 500 000 ₽ — цена зависит от количества модулей (авторизация, платежи, каталог продуктов), глубины интеграции с внутренними системами банка и требований к безопасности. Точный расчёт под конкретный проект можно получить на странице тарифов.

Реально ли уложиться в 6 месяцев для сложного финтех-проекта?

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

Как обеспечивается защита персональных данных клиентов в приложении?

Персональные данные — ФИО, паспортные данные, номер счёта — хранятся в отдельном зашифрованном контуре с журналом доступа, что соответствует требованиям 152-ФЗ. Такую архитектуру закладываем на этапе аудита, а не достраиваем перед релизом, когда изменения обходятся дороже.

Можно ли интегрировать мобильное приложение с 1С, если у компании там ведётся учёт?

Да, мы строим отдельный API-слой между приложением и 1С, чтобы данные — балансы, сверки, комиссии — обновлялись автоматически, без ручного переноса. Такой подход убирает ошибки оператора и снимает риск расхождения данных между приложением и учётной системой.

Что делать, если во время разработки нагрузочное тестирование показывает сбои?

Не откладывать релиз, а точечно исправлять узкое место — в нашем случае это был модуль авторизации при пиковой нагрузке. Мы выносим проблемный компонент на отдельный сервис, добавляем кэширование там, где оно оправдано, и повторяем тест перед тем, как двигаться дальше по графику.