No-code для FinTech MVP: когда работает, а когда ломает продукт

No-code для FinTech MVP кажется очевидным выбором: быстрее, дешевле, не нужна команда разработчиков. Основатель запускает Bubble, строит интерфейс за выходные и чувствует себя гением эффективности. Потом приходит первый корпоративный клиент, просит подключиться к их банковскому API — и проект встаёт. Это не редкий сценарий. Это типичный финал истории «no-code для fintech mvp».

Что умеют современные no-code инструменты — честная картина

Прежде чем разбирать ловушки, стоит признать: no-code платформы за последние три года сделали колоссальный скачок. Bubble позволяет строить сложные web-приложения с базой данных, авторизацией и API-интеграциями — без единой строки кода. Webflow даёт профессиональный фронтенд с анимациями и CMS. Glide превращает Google Sheets в мобильное приложение за час.

Для большинства продуктовых задач этого достаточно. Маркетплейс, CRM, портал бронирования, внутренний инструмент — no-code закрывает эти задачи хорошо. Проблема начинается, когда слово «FinTech» появляется в описании продукта.

Три сценария, когда no-code подходит для FinTech стартапа

Сценарий 1 — Лендинг с формой предзаписи

Вы ещё не разрабатываете продукт, а собираете сигнал спроса. Webflow + Typeform + Zapier — идеальный стек. За два дня получаете убедительный лендинг, форму, автоматическую рассылку для waitlist. Это не продукт — это валидация. No-code здесь не просто уместен, он является правильным инструментом.

Сценарий 2 — Прототип для CustDev

Вам нужно провести 20 интервью с потенциальными пользователями и показать им кликабельный прототип. Bubble отлично справляется: вы строите внешне убедительный интерфейс, добавляете тестовые данные, имитируете основной сценарий. Инвесторы на pre-seed стадии принимают такие демо. Пользователи дают полноценную обратную связь по UX. Это честный прототип — и он делает свою работу.

Сценарий 3 — Простой аналитический дашборд

Ваш FinTech продукт уже запущен, и HR-директор клиента хочет видеть сводку по транзакциям сотрудников. Это read-only интерфейс с фильтрами и экспортом в Excel. Retool или AppSmith строят такие инструменты за несколько дней и работают надёжно — потому что здесь нет обработки платежей, нет персональных данных в транзите, нет compliance-требований.

Четыре сценария, когда no-code сломает FinTech-продукт

Сценарий 1 — PCI DSS и платёжные данные

Если ваш продукт обрабатывает данные банковских карт — вы попадаете под стандарт PCI DSS. Это не рекомендация, а требование платёжных систем. PCI DSS предъявляет конкретные технические требования: шифрование данных в определённых форматах, логирование всех операций с картами, ограничение доступа по принципу least privilege, регулярный аудит.

Bubble хранит данные в своей облачной инфраструктуре. У вас нет полного контроля над тем, как именно они хранятся, шифруются и логируются. Пройти PCI DSS аудит с продуктом на Bubble технически возможно только в теории — на практике ни одна компания по безопасности не сертифицирует такое решение. Visa и Mastercard это знают.

Сценарий 2 — Real-time транзакции и latency

No-code платформы добавляют слой абстракции между вашей бизнес-логикой и исполнением. Bubble обрабатывает каждое действие через свой интерпретатор — это работает для большинства задач, но создаёт проблемы при требованиях к latency менее 200 мс. Платёжные сценарии, антифрод в реальном времени, скоринговые запросы к ML-модели — всё это требует предсказуемой и контролируемой производительности.

Один из наших клиентов пришёл к нам после шести месяцев работы на Bubble. Их кредитный MVP показывал latency скоринга 1,8–3,2 секунды. Пользователи бросали заявки на полпути. После переноса на FastAPI + CatBoost latency упала до 140 мс. Конверсия выросла на 34%.

Сценарий 3 — Интеграции с банками и платёжными системами

Российские банки предоставляют API для интеграции — но эти API требуют строгой аутентификации (OAuth 2.0 + mTLS), обработки специфических форматов данных и реализации логики согласно банковским стандартам. Тинькофф, Сбер, ЮKassa — у каждого своя специфика, свои требования к retry-логике, обработке ошибок, webhook-ам.

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

Сценарий 4 — Масштабирование и vendor lock-in

Предположим, ваш FinTech MVP на Bubble выстрелил. У вас 10 000 пользователей и первый крупный корпоративный клиент. Он просит развернуть продукт в их инфраструктуре — по требованиям безопасности их IT-отдела данные должны быть на их серверах. Bubble это не позволяет. Весь ваш продукт живёт в облаке Bubble, и вы не можете его «забрать».

Это vendor lock-in в самом жёстком виде. Переезд означает переписывание с нуля. Те «сэкономленные» 500 тысяч рублей на старте превращаются в 2–3 миллиона на переезде — плюс потеря времени и риск потери клиента.

Скрытые расходы no-code: считаем честно

Bubble Personal Plan — 32 долларов в месяц. Звучит дёшево. Добавим реальную картину:

• Плагины: большинство нужных интеграций — платные плагины от сторонних разработчиков. Нужна SMS-верификация? Плагин. KYC через Sumsub? Плагин. Экспорт в Excel? Плагин. Суммарно — ещё 100–300 долларов в месяц, и каждый плагин — потенциальная точка отказа при обновлении Bubble.
• Масштабирование: при росте трафика Bubble требует перехода на Production Plan (349 долларов/мес) или Dedicated Plan (от 450 долларов/мес). Плюс каждый дополнительный пользователь в базе данных начинает стоить денег.
• Разработчик Bubble: «без кода» — это маркетинг. Сложный продукт требует опытного Bubble-разработчика. Их ставки — 2 500–5 000 рублей в час. Квалифицированных специалистов мало, их найм занимает время.
• Переписывание: по нашей оценке, 70% FinTech стартапов, начавших с no-code, переписывают продукт на полноценный стек в течение 18 месяцев. Стоимость переписывания — от 1,5 до 3 миллионов рублей.

Альтернатива: low-code API-first подход

Есть позиция между «всё на no-code» и «пишем с нуля на чистом коде». В IT2BE мы используем API-first подход с проверенными компонентами: FastAPI для backend, React для frontend, готовые библиотеки для KYC и платёжных интеграций.

Это не значит «дольше». Это значит «правильнее». На Discovery мы за один день определяем, какие части продукта можно строить быстро на готовых компонентах, а какие требуют кастомной реализации из соображений compliance или производительности. Результат — код, который вы владеете, который можно развернуть в любой инфраструктуре, который проходит проверку безопасности.

22 рабочих дня и фиксированная цена до 900 000 рублей — это не лозунг. Это результат того, что мы знаем FinTech изнутри и не тратим время на объяснение, что такое PCI DSS или как работает ЮKassa API.

Итог

No-code — это инструмент, а не религия. Для лендинга, прототипа и внутреннего дашборда — отличный выбор. Для FinTech MVP, который должен обрабатывать платежи, соответствовать регуляциям и масштабироваться — ловушка, которая выглядит как экономия, а стоит как переписывание.

Прежде чем выбрать платформу для вашего FinTech MVP, задайте себе три вопроса: будет ли продукт обрабатывать платёжные данные? Есть ли требования к latency менее 500 мс? Может ли корпоративный клиент потребовать развёртывание в своей инфраструктуре? Если хотя бы один ответ «да» — вам нужна полноценная разработка.

Если хотите разобрать вашу конкретную ситуацию — запишитесь на Zoom-колл с командой IT2BE. За час разберём архитектуру, определим правильный стек и дадим честную оценку: что строить на no-code, а что требует кода.