Как создать международное приложение: кейс VanDao
Когда китайский предприниматель решает выйти на российский рынок, первая проблема — не поставки, а понимание: как заключить договор, где найти юриста, как всё оформить, если ты не говоришь по‑русски. Именно эту задачу решала команда Iconica, когда к нам пришли с идеей мобильного приложения, способного соединить две культуры, два языка и один бизнес‑интерес — понятно, быстро и юридически грамотно. Мы расскажем, как всего за три месяца разработали MVP, в котором чат, CRM, переводчик и SOS‑функция работают как единое целое — и почему это было не просто про код, а про архитектуру доверия.
Шаг 1. Понять, что MVP — это не компромисс, а ускорение
Компания Iconica специализируется на разработке digital‑решений под бизнес‑задачи: от CRM‑автоматизации до сложных платформ. К нам обратился клиент, который хотел сделать почти невозможное — соединить китайских предпринимателей, начинающих вести бизнес в России, и русскоязычных юристов, которые могли бы им помочь. Между ними — языковой барьер, разница в правовых системах и ноль цифровых решений. Именно это пространство мы и должны были заполнить.
Задача звучала просто: сделать MVP — мобильное приложение, в котором стороны смогут общаться, обмениваться документами и запускать сделки. Но за этой простотой скрывался целый комплекс ограничений: короткий срок (3 месяца), требование к масштабируемости, и главное — юридическая ответственность, где всё должно работать без ошибок с первого дня.
Мы приняли решение идти по пути MVP, но не как временной «черновик», а как продуманный старт масштабного продукта с возможностью роста. Такой подход требует не упрощения, а выстраивания чёткой архитектуры и понимания приоритетов.
Рассылка: как вести бизнес в России
Пять полезных писем пришлем сразу после подписки. В них — бизнес‑идеи, готовые промпты для нейросетей, советы, как выбрать налоговый режим и получать пассивный доход
Шаг 2. Выстроить технологическую архитектуру, которая не сломается при первом росте
Сначала мы проанализировали, как будет работать это приложение: от регистрации пользователя до завершения сделки. Важно было не просто «соединить по чату», а создать понятную цепочку действий: подача заявки, выбор исполнителя, согласование суммы, подписание договора, оплата и сопровождение. При этом интерфейс должен быть интуитивно понятным как для китайского предпринимателя, который никогда не сталкивался с российскими платформами, так и для русского юриста, привыкшего работать в мессенджерах или Excel.
Ключевым решением стало использование Битрикс24 как центра управления логикой. Битрикс позволил встроить в экосистему CRM, авторизацию, систему уведомлений и даже SOS‑функцию — и всё это без необходимости создания кастомной backend‑архитектуры с нуля. Мы интегрировали Bitrix с Flutter (для кроссплатформенной разработки), WebView (чтобы подключить backend напрямую в приложение), нейросетевым переводчиком DeepL и хранилищем документов на Yandex S3. Такой технологический стек дал нам гибкость, надёжность и возможность масштабирования.
Вся архитектура строилась по принципу «лего»: каждый сервис работал независимо, но взаимодействовал через единый центр — Битрикс24. Это дало стабильность и позволило избежать хаоса на финальных этапах сборки.
Шаг 3. Реализовать функции, которые делают приложение «живым»
На выходе мы получили продукт, который работает почти как Uber — только в юридической сфере. Пользователь может выбрать юриста, оформить заказ, оплатить услугу и, при необходимости, нажать кнопку SOS — и всё это без единого слова по‑русски. Когда юрист пишет по‑русски, китайский пользователь мгновенно получает перевод на свой язык. Причём не сухой машинный перевод, а адаптированный под деловой стиль. Это было реализовано через нейросетевой перевод и кастомную логику от Iconica, встроенную прямо в CRM.
Интерфейс также стал ключевым элементом успеха. Минимализм, крупные кнопки, понятная логика — мы провели десятки быстрых тестов, чтобы убедиться: пользователь без знания языка сможет выполнить целевое действие за 2–3 клика. Скорость и стабильность тоже были приоритетами — от отклика до загрузки документов. По сути, приложение получилось лёгким и быстрым, несмотря на комплексную архитектуру.
Шаг 4. Решать проблемы — не когда они появились, а заранее
По нашим наблюдениям, многие предприниматели недооценивают этап публикации в сторах. Часто к этому подходят как к финальной загрузке APK или сборки — формально и «по остаточному принципу». На практике же это отдельный трек проекта, особенно если вы работаете на стыке юридических услуг, кроссбордер‑коммуникаций и встроенных платёжных механизмов.
Наш проект затрагивал сразу несколько «чувствительных зон» — это юридическая специфика, обработка персональных данных, мультивалютные операции, плюс локализация под две совершенно разные цифровые среды: российскую и китайскую. Сторы реагируют на такие приложения как на потенциально рискованные: проверяются не только технические компоненты, но и сама бизнес‑модель, формулировки в описаниях, даже тексты кнопок.
App Store, например, легко отклоняет релиз из‑за использования термина “legal advice”, даже если у вас просто структурированная база знаний. Любая форма обработки платежей требует внятной логики взаимодействия с пользователем, наличия документов на русском и английском, подписанных по формальным требованиям. Ошибки в маршрутизации, отсутствие раздела T&C или некорректное описание функционала в metadata могут заморозить релиз на недели.
Публикация в WeChat оказалась ещё сложнее. Китайский digital‑рынок по сути «суверенный», с нестабильными API, отсутствием публичной документации и закрытой системой допуска через платформу Tencent. Мы столкнулись с необходимостью прохождения верификации на стороне китайского юрлица, ограничения по структуре интерфейса и даже адаптацией текста и иконок под стандарты китайской UX‑культуры.
То, что помогло пройти этот путь — грамотная архитектура. Мы с самого начала заложили компонентную структуру, которая позволила быстро изолировать модули: платежи, локализацию, пользовательские сценарии. Благодаря этому мы поэтапно запускались: сначала в RuStore, потом Android (Google Play), и далее готовим релиз под App Store. Китайская сборка реализована как отдельный слой с минимальными пересечениями, что даёт нам гибкость в сопровождении.
Это одна из тех вещей, которую не видно снаружи — ни заказчику, ни конечному пользователю. Но именно архитектурное решение на старте определяет, сможете ли вы масштабироваться на другие рынки или увязнете в переписываниях под каждый новый стор.
Шаг 5. Сделать не просто приложение, а цифровой мост
После запуска MVP команда продолжает развивать функциональность продукта. В ближайшие планы входят: переход к более глубокой кастомизации пользовательских сценариев, реализация нативной версии под iOS, а также внедрение расширенной системы транзакций с безопасной логикой сопровождения сделок.
Благодаря гибкой архитектуре, заложенной на старте, продукт адаптируется под несколько юрисдикций и пользовательских моделей. Особое внимание уделяется правовым ограничениям, безопасности обмена данными и локализации под специфику двух рынков — российского и китайского.
Проект продолжает развиваться как инструмент для ускорения взаимодействия между пользователями из разных стран, особенно в тех ситуациях, где требуется быстрое оформление запроса, юридическое уточнение или согласование условий.
