Как мы разработали финтех‑сервис по автоматизированному поиску инвесторов для малого бизнеса

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

С какой задачей к нам пришел клиент

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

Ключевые ограничения на старте:

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

Фактически речь шла не просто о разработке сайта, а о построении цифровой финансовой инфраструктуры.

Как реализовывали проект: пошаговый процесс

Разработка велась итерационно, с регулярными стратегическими сессиями с заказчиком.

Команда проекта:

• backend- и frontend‑разработчики;
• UX/UI‑дизайнер;
• аналитики;
• DevOps‑инженер;
• тестировщики;
• менеджер проекта.

Шаг 1. Разделение ролей и пользовательских сценариев

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

Этап 1. Анализ сценариев. Мы разложили путь инвестора и заёмщика на отдельные пользовательские сценарии: от регистрации до завершения сделки. Это позволило увидеть, где процессы пересекаются, а где логика принципиально разная.

Этап 2. Проектирование отдельных кабинетов. На основе сценариев были спроектированы два разных личных кабинета с разной логикой, интерфейсом и доступными действиями. Общие элементы сознательно выносились в системный уровень, а не в UI.

Этап 3. Ограничение прав на уровне системы. Мы зафиксировали роли не только в интерфейсе, но и в backend‑логике — пользователь физически не может выполнить действия, не относящиеся к его роли.

Это решение позволило:

• сократить количество пользовательских ошибок;
• упростить интерфейс;
• снизить нагрузку на поддержку;
• повысить конверсию на ключевых этапах.

Шаг 2. Автоматизация юридических процессов

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

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

Этап 2. Автоматическая генерация документов. На основе этих правил система начала автоматически формировать договоры и графики платежей без участия менеджеров. Все данные подтягиваются из системы, без ручного ввода.

Этап 3. Подтверждение операций через SMS. Мы внедрили SMS‑подтверждение как юридически значимый шаг. Это позволило отказаться от бумажных подписей и сократить время сделки с дней до минут.

Основная сложность заключалась в балансе между UX и требованиями регулятора. Юридически всё должно быть безупречно, но пользователь не должен ощущать сложность процессов.

Шаг 3. Упрощение входа для инвесторов

Один из ключевых барьеров на рынке — высокий порог входа. В PANFILOV Invest он был снижен до 500 ₽.

Этап 2. Удобные финансовые операции. Реализовали пополнение счёта через QR‑коды, быстрый вывод средств и возможность менять сумму инвестиций без обращения в поддержку.

Этап 3. Защита пользователя от неудачных сценариев. Система автоматически возвращает средства, если проект не набрал нужный объем, и позволяет выйти из проекта до окончания раунда.

Шаг 4. Прозрачность финансов и аналитика

В личном кабинете инвестора вся финансовая информация собрана на одном экране:

• общий объем инвестиций;
• средства в проектах;
• полученная и ожидаемая прибыль;
• история операций.

Как мы реализовали это решение по шагам.

Этап 1. Определение ключевых метрик. Мы определили, какие показатели действительно важны инвестору: вложено, в работе, получено, ожидается.

Этап 2. Сбор данных в одном интерфейсе. Вся финансовая информация была собрана в одном экране личного кабинета без необходимости переходить между разделами.

Этап 3. История операций и детализация. Каждая операция имеет понятную расшифровку и историю, что снижает количество вопросов и спорных ситуаций.

Это решение заметно сократило количество вопросов в поддержку.

Шаг 5. Интеграция и учёт

Этап 1. Проектирование учетной модели. Мы заранее определили, какие данные и в каком виде должны передаваться в бухгалтерию и налоговый учет.

Этап 2. Настройка автоматического обмена данными. Интеграции были выстроены так, чтобы операции учитывались автоматически, без ручного дублирования данных.

Этап 3. Проверка на реальных сценариях. Мы тестировали интеграции не на абстрактных данных, а на реальных пользовательских сценариях и сделках.

Сложно совместить требования учёта, регулятора и пользовательского опыта в одном приложении. Решением стало проектирование интеграции на раннем этапе, а не «после запуска».

Итоги и выводы

За год мы прошли путь от идеи до полноценного финтех‑сервиса и хотим поделиться универсальными выводами для тех, кто планирует запуск инвестиционной платформы:

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

Финтех‑продукты разрабатываются ради доверия клиентов, устойчивости и системности. И именно эти ценности нужно закладывать в основу ещё до первой строки кода.