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

Flutter подходит для финтеха, потому что рисует интерфейс сам. Кастомный график, дашборд портфеля или список операций ведут себя одинаково на iOS и Android из одной кодовой базы — примерно на 30–40% дешевле, чем делать тот же продукт дважды нативно. То, что напрямую касается платформы, — аппаратное хранение ключей, платёжные шторки, часть -SDK — идёт через : это рутина, но это реальная работа.

Какие продукты мы делаем

  • Инвестиционные и торговые приложения — портфели, списки наблюдения, заявки и экраны с графиками, которые не тормозят при живых котировках
  • Необанки и банковские клиенты — счета, переводы, выписки, управление картами и онбординг со сканированием документов
  • Платёжные продукты и кошельки — оплата, история операций, регулярные платежи и нативные платёжные шторки
  • Личные финансы и кэшбэк — агрегация, категоризация и механика вознаграждений, как в кэшбэк-платформе, которую мы построили
  • Иншуртех — расчёт стоимости страховки, оформление страховых случаев и управление полисами, где пайплайн документов и фото важнее дашборда

Кто будет делать ваше финтех-приложение

Команду, которая может сделать финансовое приложение, от команды, которая делала просто приложения, отличают две вещи.

Платёжная инфраструктура, проверенная на масштабе

Nerdy Production возглавляет Илья Никсан, ранее CTO QIWI — одной из крупнейших платёжных платформ на своём рынке, где он руководил примерно 12 инженерными командами: от веб-продуктов до карточного процессинга, зоны и бесконтактных платежей. Он построил бесконтактную оплату картой на Android через поверх ISO/IEC 14443, с платёжным протоколом EMV Contactless (Visa PayWave), и выпустил NFC-оплату картой примерно за год до того, как на рынке появился собственный Android Pay от Google. Он также был архитектором терминала Evotor — устройства на форкнутом , работающего на кассах в продакшене.

Что это значит для вас: человек, который ведёт вашу разработку, эксплуатировал регулируемую платёжную инфраструктуру, отвечал за зону PCI-DSS и выпускал card-present сценарии оплаты, а не просто писал приложения, вызывающие платёжное API.

Финтех-продукт, уже опубликованный в обоих сторах

Мы сделали ExtraETF для Isarvest GmbH в 2022 году — инвестиционное приложение на Flutter с бэкендом на Go: рыночные данные в реальном времени, интерактивные графики и учёт портфеля, опубликованное в App Store и Google Play. Технический разбор — в статье Как мы делали финтех-приложение реального времени на Flutter и Go, включая по , которая держит поток котировок, не перегружая клиент.

Что на самом деле требуют финтех-приложения

В каждом финансовом проекте возникают пять задач. Вот как мы решаем каждую.

Рыночные и транзакционные данные в реальном времени

Цены, балансы и статусы заявок меняются непрерывно, и интерфейс должен это переваривать, не роняя кадры и не теряя позицию скролла. В ExtraETF решением стал сервис на Go, раздающий рыночные данные через WebSocket, вместе с клиентом, который сужает перестройки до реально изменившейся серии. Наивная реализация — перестраивать поддерево виджетов на каждом тике — это ровно то, из-за чего экраны с графиками дёргаются на среднем Android-железе.

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

Безопасность и комплаенс

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

  • Учётные данные в iOS Keychain и Android Keystore, а не в shared preferences
  • с пиннингом сертификатов и планом ротации, который не ломает старые клиенты
  • Биометрия и код-пароль на чувствительных действиях, а не только при запуске
  • Шифрование локального хранилища для всего, что кэшируется на устройстве
  • Никаких персональных и финансовых данных в логах, крэш-репортах и аналитике
  • Карточные данные вне зоны вашего приложения везде, где это позволяет SDK провайдера

Архитектурные ограничения, которые накладывают PCI-DSS, GDPR, SOC 2 и KYC/AML, — это решения, которые принимают заранее или оплачивают потом; ровно этот опыт наш основатель вынес из карточного процессинга. На практике это значит решить заранее, каких данных ваше приложение вообще имеет право касаться: ввод карты отдан SDK провайдера, чтобы сырой PAN не доходил до вашего кода; персональные данные разделены так, чтобы запрос на удаление по GDPR был запросом к базе, а не археологией; журнал аудита спроектирован вместе с функцией, а не прикручен, когда его впервые попросят. Архитектуру, которой мы придерживаемся, и места, где она незаметно ломается, разбирает наш материал про шифрование в мобильных приложениях.

Точная денежная арифметика

Деньги никогда не бывают числом с плавающей точкой. В 0.1 + 0.2 не равно 0.3, и в финансовом приложении эта ошибка округления вырастает в несошедшуюся сверку. Мы храним суммы целыми числами в наименьших единицах валюты — в копейках, а не в рублях — или используем decimal-тип, а правила округления держим явными и покрытыми тестами на каждой границе — отображение, API, хранилище. Подробный разбор — в статье Почему 0.1 + 0.2 ≠ 0.3.

Платежи, подписки и доступы

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

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

Производительность и надёжность

У пользователей финансовых приложений низкая терпимость к спиннеру там, где должен быть баланс. Это значит 60fps на экранах с графиками — на реальных устройствах, а не на флагманских симуляторах, offline-first, чтобы кэш отрисовывался мгновенно, пока грузятся свежие данные, и состояния ошибок, которые говорят, что произошло, вместо тихого показа устаревшей цифры. Вопрос «когда это число было верным в последний раз?» мы считаем полноценной частью состояния интерфейса и тестируем на среднем Android-железе, которое реально в руках у ваших пользователей.

Почему Flutter для финтеха

Честный аргумент за Flutter здесь:

ТребованиеКак это решает Flutter
iOS и Android одной командойОдна кодовая база, примерно на 30–40% дешевле двух нативных
Кастомный финансовый UI — графики, дашбордыFlutter рисует пиксели сам, поэтому сложный UI идентичен на обеих платформах
Плавность под живыми даннымиКомпилируется в нативный код; 60fps достижимы при аккуратном сужении перестроек
Платформенные примитивы безопасностиKeychain, Keystore и биометрия — через platform channels
SDK вендоров для KYC и платежейУ многих есть Flutter-пакеты; чисто нативные требуют обёртки

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

Где нативная разработка всё ещё выигрывает: если ваш продукт по сути тонкая обёртка вокруг платформенной возможности — глубокая интеграция с Apple Wallet или card-present NFC-сценарий, завязанный на стек одной платформы, — преимущество кроссплатформенности схлопывается, и честным ответом может быть нативная разработка. Мы скажем, если это ваш случай. Общая страница услуги — разработка на Flutter.

Как мы работаем

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

Staff augmentation. Наши инженеры входят в вашу команду, в ваш репозиторий и спринты, под ваше управление. Подходит, когда инженерное руководство уже есть и нужна мощность на Flutter — см. расширение команды и наш гайд по найму Flutter-разработчиков, который честно говорит и о том, когда нас брать не стоит.

В обоих случаях смету под задачу мы присылаем за два рабочих дня после того, как поймём требования.

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

Что чаще всего спрашивают команды, которые строят финансовые продукты на Flutter.

Да. Flutter хорошо подходит для финтех-приложений, потому что рисует интерфейс сам: кастомные финансовые экраны — графики, дашборды портфеля, списки операций — ведут себя одинаково на iOS и Android из одной кодовой базы, обычно на 30–40 процентов дешевле, чем разработка двух нативных приложений. Он компилируется в нативный код, поэтому производительность под живыми рыночными данными достижима. Компромисс в том, что платформенные возможности вроде аппаратного хранения ключей, платёжных шторок и части KYC-SDK доступны через platform channels, а не напрямую: это рутинная, но реальная инженерная работа.
Да, и он уже используется в продакшн-приложениях банков и брокеров. Flutter не меняет вашу защищённость, потому что использует те же платформенные примитивы, что и нативное приложение: iOS Keychain, Android Keystore, биометрические API и пиннинг сертификатов — всё через platform channels. Безопасность финансового приложения определяется дисциплиной реализации, а не UI-фреймворком. На практике мы видим три провала: учётные данные в незащищённом хранилище, персональные данные в логах и отсутствие пиннинга — и все три встречаются в нативных кодовых базах ровно так же часто.
Да, и это та часть, которая больше всего выигрывает от осознанной инженерии. Мы сделали ExtraETF, работающее инвестиционное приложение, на Flutter с бэкендом на Go, который раздаёт рыночные данные через WebSocket. Типичный провал — перестраивать большие поддеревья виджетов на каждом тике цены, из-за чего на средних устройствах падают кадры. Лечится это сужением перестроек до реально изменившихся данных и правильной гранулярностью обновлений на транспорте, а не проталкиванием каждого тика прямо в дерево виджетов.
Никогда не числами с плавающей точкой. В IEEE 754 0.1 плюс 0.2 не равно 0.3, и в финансовом приложении эта ошибка округления накапливается до несошедшейся сверки. Мы храним денежные суммы целыми числами в наименьших единицах валюты — в копейках, а не в рублях — либо используем decimal-тип, и делаем правила округления явными и покрытыми тестами на каждой границе, где деньги показываются, передаются или сохраняются. Это требование корректности, а не вопрос вкуса.
Сфокусированный первый релиз со счетами, основными операциями и одним-двумя ключевыми экранами обычно занимает от трёх до пяти месяцев разработки. Брокерское или банковское приложение с живыми рыночными данными, KYC-онбордингом и интеграциями платёжных провайдеров идёт дольше, потому что сроки задают сторонние интеграции и циклы ревью, а не работа над интерфейсом. Разбор того, как объём, бэкенд, интеграции и комплаенс складываются в итоговую цифру, — в нашем гайде по стоимости разработки на Flutter.
Да. Flutter-приложения интегрируют платёжные шлюзы, нативные встроенные покупки для цифровых товаров и тарифы подписок с проверкой доступов. Инженерная сложность не в основном сценарии, а в граничных случаях: восстановление покупок на новом устройстве, подписка, истёкшая посреди сессии, и платежи, прошедшие у провайдера, но не подтвердившиеся на бэкенде. Состояние доступа мы держим на сервере, а клиент лишь отражает его, поэтому заплативший пользователь никогда не потеряет доступ из-за предположения, сделанного на клиенте.
Нет, и стоит скептически смотреть на любое приложенческое агентство, которое предлагает сертификацию как аргумент продажи вместо описания того, как оно строит. Сертификация относится к организации, которая обрабатывает данные, — для большинства финтех-продуктов это вы и ваш платёжный провайдер. Мы даём архитектуру, которая держит карточные данные вне зоны вашего приложения там, где это позволяет провайдер, и основателя, который отвечал за зону PCI-DSS и вёл карточный процессинг в крупной платёжной платформе, — поэтому ограничения закладываются в проект с самого начала, а не обнаруживаются на аудите.

Разбор стоимости — в статье Стоимость разработки Flutter-приложения в 2026 году, а посмотреть, как выглядит выпущенный финтех-продукт на Flutter, можно в кейсе ExtraETF.