Когда клиент спрашивает «на чём вы делаете», и в ответе слышит «мы пишем на Flutter» или «у нас стек React Native» — это первый красный флаг. Студия, у которой один стек на все случаи, выбирает не под задачу, а под свою команду. И это нормально для аутстаффа — но это не партнёр в продукте.
Эта статья — про то, как мы выбираем стек. Шесть вопросов, в каком порядке мы их задаём, и как ответы приводят к решению.
01 · Главная ошибка студий
Большинство ошибок выбора стека делятся на два типа:
- «Выбрали то, что знаем». Команда умеет в Flutter — все проекты идут на Flutter, даже когда задача про нативные камеры с биометрией, и нативка решает её в три раза быстрее.
- «Выбрали то, что модно». 2024 — React Native, 2025 — Compose Multiplatform, 2026 — что там сейчас? Студия гонится за хайпом, продукт страдает через год, когда фреймворк устарел.
Стек выбирают под задачу, размер бюджета и команду клиента, которая будет с этим жить дальше. Никак иначе.
02 · Шесть вопросов, в порядке важности
Эти вопросы мы задаём на втором этапе («Архитектура и смета»). До того как технология появится в коммерческом предложении.
- Кто будет сопровождать продукт через 2 года? Если вы сами не разработчик — стек должен быть массовым (легко найти подрядчика на замену). Если у вас своя команда — спросим у них.
- Какие функции продукта зависят от платформы? Камера, биометрия, Bluetooth, фоновые задачи, push-уведомления специфичных типов — это нативные API. Чем их больше, тем сильнее аргумент за нативку.
- Какой объём UI кастомный, а какой стандартный? Стандартные списки и формы — отлично на Flutter. Сложные жесты, кастомные анимации с физикой — нативка читается легче.
- Какой целевой пользователь и платформа? iOS-only при бюджете на одну платформу — Swift, без вариантов. Android-only массовая аудитория — Kotlin. Обе платформы при ограниченном бюджете — cross-platform.
- Какая нагрузка ожидается на сервер? Это про бэкенд. До 10k DAU — NestJS на TypeScript хватает. Real-time на 100k — Go. AI-обработка тяжёлая — Python.
- Какие интеграции уже определены? СБП, эквайринг, банковские API, конкретные SDK — иногда они есть только на одной платформе/языке. Это сужает выбор.
03 · Когда выбираем Swift и Kotlin
Нативная разработка — почти всегда наш выбор для бюджетов выше среднего, потому что:
- Производительность критична, особенно с камерой, аудио, real-time
- Часть пользователей будет ругаться, если приложение «тормозит как сайт» — Apple-аудитория особенно
- Долгосрочное сопровождение проще: технология не зависит от прихоти Google/Meta
Примеры наших проектов на нативе: таксопарк (Swift + Kotlin), музыкальный AI (Swift), садовод (Swift, потому что Core ML).
04 · Когда — Flutter
Flutter выбираем, когда:
- Бюджет ограничен и нужны обе платформы
- UI кастомный и «своего цвета» (Flutter рендерит сам, не подстраиваясь под платформу)
- Команда клиента, которая будет дальше развивать, уже умеет в Dart
Наши примеры: финансовый дашборд (был жёсткий бюджет на iOS+Android), CRM для салонов (стандартный UI, обе платформы).
05 · Когда — React Native
RN для нас стал нишевым: используем, если у клиента уже есть веб-команда на React. Тогда code-sharing реально работает, и команда подхватывает мобайл без переучивания.
Пример: IT-баттл — клиент уже имел веб-часть на React, нам было дешевле сделать RN, чем заводить новую команду.
06 · Бэкенд: Nest vs Go vs Python
Здесь правило простое:
- NestJS на TypeScript. Стандартный выбор. CRUD-проекты, средние нагрузки, понятная для большинства подрядчиков архитектура. Этим мы делаем 80% бэкендов.
- Go. Когда ожидаем real-time на тысячах коннектов, или микросервисы, которые должны держать высокую нагрузку при минимальных серверах. Таксопарк бэкенд на Go.
- Python (FastAPI или Django). Когда сердце продукта — AI/ML. Воображариум на Python, потому что нужны LLM-цепочки, и сообщество Python даёт самые свежие библиотеки.
Технология — это не цель и не повод гордиться. Это просто инструмент. Выбираем под задачу, не под себя.
Если хотите конкретный ответ на «какой стек подходит под мою идею» — это часть нашего бесплатного разбора. Пришлём с обоснованием.