Оценить проект
EN
ОЦЕНИТЬ ПРОЕКТ
Продолжая использовать этот сайт, вы соглашаетесь на использование файлов cookie 🍪
Ок
3 месяца
Срок проекта
$7 млн инвестиций
Критерий успеха
RxDart
Firebase
Flutter
GitHub Actions
Widgetbook
Мобильное приложение

Мобильный кошелек ZAR
на блокчейне Solana

Задача

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

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

Технологии

О проекте

ZAR — мобильный кошелек на блокчейне Solana. Пользователи уже могут выпускать виртуальные банковские карты с поддержкой Apple Pay и Google Pay, а также пополнять баланс с помощью криптовалюты. Команда проекта стремится создать сервис, который будет позволять обменять наличные на цифровые доллары (USDC) через сеть локальных агентов. Пользователю будет достаточно отсканировать QR-код, передать наличные и мгновенно получить стейблкоины на счет.

Команда

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

Мы начали сотрудничество с ZAR на самом раннем этапе развития продукта — один из наших разработчиков подключился к проекту на парт-тайме. После работы с нашим специалистом и проведенного аудита заказчик решил передать всю мобильную разработку нам. Мы подключили еще двух специалистов — команда выросла до трех человек.

Результат

Команда CosySoft заложила основу для развития мобильного приложения ZAR. Мы не начинали проект с нуля, но пришли в момент, когда внутренней инфраструктуры не было: слабо налажены процессы, CI/CD, контроль качества, стабильная архитектура. Мы закрыли ключевые пробелы в инфраструктуре, архитектуре и качестве кода, что позволило команде безопасно масштабироваться.

Настройка CI/CD-процесса

Первой задачей было внедрение базового CI/CD. Заказчик хотел, чтобы сборки автоматически попадали в тестовую среду без ручной подготовки билдов.

Мы настроили процесс деплоя через GitHub Actions. Каждое изменение автоматически собиралось и разворачивалось для тестирования. Это позволило команде ускорить цикл проверки новых фич и упростить контроль качества

Аудит и доработка функционала

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

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

Подход оправдал себя: базовый функционал стал работать стабильно, waitlist (лист ожидания) был доведен до рабочего состояния, ошибки в авторизации устранены. Кроме того, мы настроили автоматический мониторинг сбоев клиентской части приложения, что позволило узнавать о неисправностях и быстро вносить исправления.

Внедрение UI-кита и визуального тестирования

Мы реализовали UI-кит на основе дизайн-системы клиента и внедрили систему визуальных примеров компонентов (виджет-бук). Это позволило команде быстро согласовывать внешний вид элементов до внедрения в приложение.

Чтобы контролировать визуальную стабильность, мы настроили golden-тестирование. Оно позволяло автоматически проверять, что UI-элементы выглядят как задумано, и не ломаются при изменениях. Особенно важно это было для кастомных компонентов, реализованных через RenderObject и CustomPainter.

Waitlist / Лист ожидания

Доработали маркетинговый инструмент Waitlist: исправили баги, улучшили UX и визуальную часть. Это было критично, так как клиент начал активно продвигать приложение и любые ошибки на входе мешали конверсии. Waitlist получил работоспособную систему наград и динамическое управление контентом. Также появились новые экраны: для взаимодействия с сетью агентов, для отображения статусов.

Архитектурная чистка и переход к модульности

Хотя проект использовал clean-архитектуру, мы выявили и устранили нарушения: модули зависели друг от друга напрямую, нарушались принципы разделения ответственности между слоями.
Команда предложила решение: реактивную архитектуру на основе событийной шины. Подготовили базовые инструменты, покрыли их тестами и задокументировали подход. Новая архитектура позволила изолировать функциональные модули, упростить командную работу и снизить риски при масштабировании.

Покрытие приложения автотестами на стабильный функционал

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

Интеграционные тесты были слишком ресурсоемкими для стартапа. Поэтому решили использовать альтернативу: виджет-тесты, которые имитируют поведение пользователя, но работают быстрее и проще в поддержке.

  • Реализовали инфраструктуру для запуска тестов.
  • Мокировали внешние зависимости (HTTP, платформенные вызовы).
  • Обеспечили тестирование флоу целиком: от ввода данных до смены экранов.
  • Подготовили шаблоны для быстрого добавления новых сценариев.

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

Вовлечение новой команды и передача знаний

Когда заказчик начал формировать внутреннюю команду, мы помогли ускорить ее вхождение в проект. Передали контекст, объяснили архитектурные решения, провели вводные сессии и участвовали в код-ревью.
Многие из новых разработчиков пришли из native-разработки и не имели опыта с Flutter. Мы консультировали их по лучшим практикам, помогали адаптировать архитектуру и упростить первые задачи.

Технологии

Проект разрабатывался на Flutter — кроссплатформенном фреймворке, который позволил переиспользовать основную часть кодовой базы на iOS и Android. Платформенные доработки были минимальны.

  • CI/CD на базе GitHub Actions с кастомными проверками и автоматическим деплоем в разные окружения. Проверки включали линтинг, тесты и специфичные правила для проекта — это помогало находить ошибки до попадания изменений в staging.
  • Widgetbook — визуальный каталог UI-компонентов. Использовался для согласования дизайна и ускорения разработки. Компоненты можно было просматривать и тестировать изолированно.
  • Golden-тесты — снапшот-тестирование UI. Помогало фиксировать визуальные состояния компонентов и отслеживать нежелательные изменения после редактирования.
  • Псевдоинтеграционные тесты на основе виджет-тестов — замена полноценных интеграционных тестов. Обеспечивали проверку флоу с симуляцией поведения внешних зависимостей. Работают быстрее и дешевле в поддержке.
  • RxDart и стримы — для реактивного взаимодействия между модулями. Позволили построить независимые части приложения с минимальными связями.
  • Кастомная реализация Firebase Remote Config — для управления фичами по флагам, включая постепенный rollout на ограниченные группы пользователей.
  • Аналитика — события отправлялись в Firebase, Amplitude и другие системы. Это обеспечивало детальное отслеживание пользовательского поведения и позволяло принимать продуктовые решения на основе данных.

Сложности проекта

Критичных проблем или конфликтов в работе не было. CTO разбирался в технических деталях и обеспечивал адекватную коммуникацию. Но полностью избежать типичных для стартапа сложностей все же не удалось.

Низкое качество кода на старте

Низкое качество кода на старте

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

Хрупкость и технический долг

Хрупкость и технический долг

До внедрения архитектурных правил и инструментов контроля состояние проекта оставалось нестабильным. Даже небольшие изменения требовали времени на анализ и повторную проверку.

Изменение процессов

Изменение процессов

Как и в любом стартапе, шло постоянное переосмысление инструментов и подходов. Менялись процессы, роли, коммуникационные каналы. Это не мешало работе, но требовало гибкости.

Итоги

Когда мы вошли в проект, у ZAR была сильная идея и продуманная маркетинговая стратегия, работающий бэкенд и минимально реализованный фронт , включая ключевую фичу waitlist , на которую делалась ставка в стратегии развития. Мы доработали эту часть и стабилизировали приложение: устранили технические ограничения, обеспечили устойчивость интерфейса, выстроили архитектуру и процессы.
После этого команда ZAR активировала маркетинговые инструменты в полную силу. Приложение стало стремительно набирать аудиторию — количество регистраций резко выросло.
Наша техническая экспертиза позволила превратить MVP в зрелый продукт, готовый к масштабированию. Это обеспечило рост метрик и помог проекту выйти на радар инвесторов. В результате ZAR закрыл раунд на $7 млн от Dragonfly Capital, a16z Crypto, VanEck Ventures, Coinbase Ventures и сооснователей Solana.

Мы передали in-house команде полностью реализованный и масштабируемый фронтенд с понятной архитектурой, стабильной инфраструктурой и готовностью к дальнейшему росту.