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

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-пакеты; чисто нативные требуют обёртки через platform channels

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

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

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

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

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

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

Сколько стоит финтех-приложение

Сфокусированный первый релиз — аккаунты, базовые транзакции и один-два флагманских экрана — это проект уровня Business: 2,7–5,4 млн ₽, за три-пять месяцев. Брокерский или банковский клиент с живыми рыночными данными, KYC-онбордингом и интеграциями платёжных провайдеров — это enterprise-работа, от от 8,1 млн ₽.

Это те же опубликованные тарифы, что и на странице разработки на 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.