🧑💻Автор: разработчик и фаундер с опытом запуска стартапов в сферах туризма, HR tech, а сейчас — в музыкальной индустрии.
🎓По образованию — Data Scientist, по призванию — Android-разработчик и продукт-менеджер.
Работал в крупных продуктах вроде X5 и Uzum, где впервые познакомился с Kotlin Multiplatform Mobile (KMM). Когда настал момент создавать прототип для своего музыкального стартапа, выбор был очевиден: я уже знал Kotlin, имел боевой опыт с KMM — и хотел быстро двигаться без лишних компромиссов.
❗️Но KMM — не единственный путь.
На столе были и Flutter, и React Native, и даже классическая нативка.
В этой статье я расскажу:
Какой стек реально помогает запускать стартапы быстро.
Почему некоторые решения выглядят красиво — но тормозят рост.
Как выбирать фреймворк не только глазами разработчика, но и через бизнес-линзу: гипотезы, бюджет, найм, поддержка.
Если ты сейчас в начале пути — читай. Если уже в бою — сверим карты.
Зачем вообще думать над выбором фреймворка?
Когда ты запускаешь стартап, особенно с ограниченным бюджетом и временем, важно не просто «написать код», а сделать это так, чтобы быстро проверить гипотезу, не вляпаться в техдолг и не потратить ресурсы впустую.
Платформ много, команд может быть мало, а требования пользователей — высоки. Поэтому важно понимать: что ты получаешь и теряешь, выбирая тот или иной стек.
Как фаундер, ты не просто выбираешь технологию — ты делаешь ставку на скорость выхода на рынок, гибкость команды и контроль над затратами. Выбор фреймворка может ускорить фандрайзинг, упростить найм, и даже решить, выживешь ли ты после первого пивота.
🔍 Примеры из индустрии
Компания | Выбор фреймворка | Почему |
Airbnb | Отказались от React Native | Много багов и интеграционных проблем |
BMW, Philips | Flutter | Кросс-платформенность и контроль над UI |
Tinkoff | KMM | Доступен Android-стек, сохраняется производительность |
Uber | Перешли на натив | Перфоманс + баги при RN |
📌Что важно учитывать при выборе фреймворка?
Критерий | Почему важен |
|---|---|
Скорость разработки | MVP должен выйти как можно быстрее, чтобы проверить гипотезу |
Стоимость и доступность кадров | Невозможно масштабироваться без доступных специалистов |
Производительность | Медленные приложения убивают удержание |
Надежность и баги | Частые баги снижают доверие пользователей и тормозят рост |
Возможность масштабирования | MVP может стать продуктом, который переживёт десятки итераций |
Производительность: цифры и реалии
Метрика | Натив | Flutter | React Native | KMM |
|---|---|---|---|---|
Cold Start (ms) | 400–700 | 800–1200 | 1000–1600 | 400–700 (натив) |
UI FPS в сложных списках | 60 fps | 58–60 fps | 40–55 fps | 60 fps (натив) |
Размер APK/IPA | 3–8 MB | 18–35 MB | 10–25 MB | 8–12 MB |
RAM usage (baseline) | 60–80 MB | 100–130 MB | 120–150 MB | как нативка |
Flutter использует свой движок (Skia), полностью рисует UI сам — это хорошо для анимаций, но вес и RAM выше.
React Native работает через JavaScript bridge — и это бутылочное горлышко при большом количестве UI-ивентов.
Нативная разработка
Когда стоит выбрать:
У вас продукт с фокусом на перформанс, нативные API (AR, Bluetooth, камера и т.д.).
Вы точно знаете, что фокус на одной платформе (например, только Android).
Вам нужен максимальный контроль над UX и визуальными эффектами.
✅ Плюсы:
Высокая стабильность и производительность.
Прямая интеграция с SDK и UI-решениями платформы.
Простая отладка, сильное комьюнити.
❌ Минусы:
Нужно писать два приложения = выше бюджет и сроки.
Любые фичи дублируются в двух кодовых базах.
Вывод: Подходит, если ты уже точно верифицировал гипотезу и идешь в прод. Для MVP — чаще избыточно, разве что у тебя в команде уже есть два нативных разработчика.
Kotlin Multiplatform Mobile (KMM)
Когда стоит выбрать:
У тебя Android-бэкграунд, ты пишешь на Kotlin.
Хочется шарить бизнес-логику, но UI оставить нативным.
Планируется рост и поддержка команды.
✅ Плюсы:
Один код на бизнес-логику, но нативный UI.
Можно переиспользовать весь net/data/core слой.
Прекрасная интеграция с Android.
Поддержка JetBrains и активное развитие.
❌ Минусы:
UI всё равно пишется отдельно.
iOS-разработчик всё равно нужен.
На iOS порой возникают сложности с отладкой shared-модуля.
Библиотеки не всегда есть или стабильны.
Уточнение: Compose Multiplatform и KMM
С недавнего времени у KMM появилась новая суперспособность — Compose Multiplatform, которая позволяет писать UI на Jetpack Compose не только для Android, но и для iOS, Desktop и Web.
Что это значит:
Ты реально можешь писать один UI-код на Kotlin — и он будет работать и на Android, и на iOS.
Это всё ещё KMM + Compose Multiplatform, но теперь ты получаешь почти Flutter-like стек, только в Kotlin-мире.К
📲 Как это выглядит? Покажу на примере нашего приложения.
IWBL — это маркетплейс, где музыканты находят TikTok-креаторов, чтобы продвигать свои треки. Особенность то что музыкант выбирает себе инфлюенсеров с опытом тикток/рилс скроллинга :)
1) Музыкант может выбрать любого тиктокера, просмотрев его видео-примеры.
2) Сделать заказ, оплатить напрямую через приложение.
3) Мы обеспечиваем безопасность: деньги перечисляются только после выполнения задания.
Мы начали с KMM + Compose Multiplatform, потому что это дало нам один код на бизнес-логику и UI — и позволило быстро запуститься на обеих платформах.
Однако, несмотря на техническую кроссплатформенность, визуально и тактильно интерфейс на iOS ощущается иначе, чем у нативных iOS-приложений.
Это ожидаемо: Material-компоненты и парадигма Compose ближе к Android. Для полноценного iOS-ощущения нужно либо вручную стилизовать UI, либо использовать специфические iOS-компоненты (что уменьшает выгоду от общего UI-кода).
Такой компромисс — осознанный. Мы знали, что важнее проверить гипотезу, чем потратить месяцы на идеальный UI под каждую платформу.
Что под капотом? | KMM + Compose MP |
UI | Jetpack Compose для Android и iOS |
Код шарится | Логика + UI |
Язык | Kotlin |
Production use на iOS | Пока ограничено (но активно развивается) |
CI/CD сложность | Выше, чем у Flutter |
Вывод
KMM — не про супербыстрый MVP, но отличный выбор, если у тебя Android-бэкграунд и ты хочешь масштабировать продукт, не дублируя бизнес-логику.
Так я и поступил со своим музыкальным стартапом: Kotlin я знаю, опыт с KMM уже был, и писать core один раз — это огромное ускорение на следующих фичах.
Flutter
Когда стоит выбрать:
У тебя небольшой бюджет и хочется запуститься одновременно на Android и iOS.
Нужна красивая кастомная UI-шка.
У команды есть опыт с Dart или желание быстро учиться.
✅ Плюсы:
Один код на две платформы.
Удобный hot reload.
Простая кастомизация интерфейса.
Быстрый старт.
❌ Минусы:
Иногда страдает производительность (особенно в сложной графике или при тяжелом скролле).
Не всегда удобно работать с нативными SDK (особенно iOS).
Вес приложения на старте может быть больше обычного.
Что будет после MVP?
Проблема | Кто страдает | Как влияет |
Техдолг | Команда разработки | MVP-фреймворк тяжело масштабировать |
Найм | Продукт / HR | Flutter- или Dart-специалистов меньше |
Отладка багов на iOS | Любая кросс-платформа | Больше времени в QA и на поддержку |
Ограничения SDK / API | Flutter / RN | Нужно писать мосты вручную |
Вывод
Идеален для MVP, особенно если ты хочешь за месяц выйти с приложением в Store и посмотреть на метрики.
React Native
Когда стоит выбрать:
У тебя сильная веб-команда с опытом React.
Вы хотите шарить код с веб-версией.
Простое приложение с минимальными нативными вызовами.
✅ Плюсы:
Один стек на все (JS, React).
Куча библиотек и решений от сообщества.
Входной порог низкий.
❌ Минусы:
Часто нужно писать бриджи для работы с нативом.
Производительность хуже Flutter.
UI-компоненты могут лагать или вести себя не так, как в нативе.
Вывод
Подходит, если у вас уже есть веб-команда, и вы хотите быстро запустить мобильную версию.
🧑🚀Вывод от автора, но решать тебе!
🧾 Табличка для ленивых 👇
Сценарий | Лучший выбор |
|---|---|
MVP за 2-4 недели | Flutter |
Сильная веб-команда | React Native |
Продукт с фокусом на UX или нативные возможности. Важность производительности | Нативка |
Android-бэкграунд, прицел на долгую жизнь продукта | KMM |
Мой выбор — KMM с Compose Multiplatform, потому что:
Я пишу на Kotlin.
У меня уже был опыт с KMM в Uzum и X5.
Я делаю ставку не только на MVP, но и на рост продукта.
Бэкенд тоже написал на котлине )
🧱 Если ты только пробуешь гипотезу — смотри в сторону Flutter.
🏗 Если строишь серьёзный foundation — подумай о KMM + Compose или нативке.
Но в любом случае — не строй собор на болоте. Сделай MVP, получи метрики, и тогда строй храм.
