Build vs buy в мобильной разработке: native, кросс-платформа, no-code

1. Сначала составьте карту продуктового риска, а не список технологий

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

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

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

2. Сравнивайте native, кросс-платформу и no-code по одним критериям

Native-разработка работает напрямую с официальным языком и интерфейсным фреймворком платформы. Это сильный кандидат, когда важны ранний доступ к новым возможностям операционной системы, платформенное поведение и тонкий контроль производительности. Цена — отдельная экспертиза, отдельный код и отдельная поверхность тестирования для iOS и Android. Общая бизнес-логика или дизайн-система сокращают дублирование, но жизненным циклом двух платформ вы всё равно управляете сами.

Кросс-платформенный подход рассчитан на выход к нескольким целям из одной кодовой базы. Он даёт преимущество при схожих продуктовых сценариях, ограниченной платформенной кастомизации и единой команде. Однако общий код не означает нулевого объёма платформенной работы. Нативные модули, правила магазинов, поведение устройств, доступность и обновления версий по-прежнему требуют отдельной проверки. Выбирая фреймворк, изучайте не только текущий каталог компонентов, но и то, кто отвечает за его поддержку.

No-code и low-code сокращают сроки в прототипах, внутренних приложениях, процессах с обилием форм и стандартных потоках данных. Там, где нужны сложная синхронизация без сети, специфическая интеграция с устройством, насыщенное взаимодействие или переносимость, границы стоит проверить рано. Право на сгенерированный код, экспорт, модель ценообразования, качество плагинов и сценарий закрытия платформы должны быть явно прописаны в договоре.

3. Читайте официальную матрицу поддержки вместе с архитектурой

Официальная матрица поддержки Flutter публикуется по версиям и показывает, какие сочетания операционной системы и оборудования поддерживаются, какие проверяются в непрерывной интеграции, а какие не поддерживаются вовсе. Список со временем меняется, поэтому вместо фразы «работает везде» из презентации сверяйте свои целевые устройства с актуальной официальной матрицей. Поддерживаемая цель не означает, что каждый плагин и каждое поведение в вашем продукте достигли одинаковой зрелости.Flutter Documentation — Supported deployment platforms

Официальное руководство Android по архитектуре рекомендует разделять ответственность интерфейса и слоя данных, опираться на единый источник истины и строить интерфейс вокруг данных, а также прямо оговаривает, что рекомендации нужно адаптировать к контексту. Эти принципы полезны не только для нативного Android: они работают как тест для любого кандидата. Насколько глубоко бизнес-логика вшита в инструмент, где находится доступ к данным, можно ли тестировать модули по отдельности?Android Developers — Guide to app architecture

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

4. Гипотетический сценарий: гибридное решение для приложения выездного сервиса

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

Кандидат на no-code быстро собирает формы и административные экраны, но упирается в ограничения на большой очереди фотографий, при разрешении конфликтов и в проверке политик устройств. Нативный кандидат даёт максимум контроля, однако команд под две платформы нет. На кросс-платформенном кандидате собирают небольшой вертикальный срез с данными без сети, камерой и фоновой отправкой, а критичный слой синхронизации проектируют как модуль, отделённый от фреймворка.

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

5. Считайте совокупную стоимость владения по жизненному циклу

Смета на первый релиз — это не полная стоимость. В бюджет входят адаптация дизайна, автотесты, парк тестовых устройств, аккаунты магазинов, наблюдаемость, обновления безопасности, апгрейды SDK, исправления доступности и переходы на новые версии операционных систем. У закупленного сервиса отдельно оцените, как меняется цена с ростом потребления, а у собственного кода — стоимость потери экспертизы и дежурств по сопровождению.

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

Не забывайте про экономику команды. Популярная на рынке технология не становится автоматически дешёвой для вашей команды. Сроки найма, баланс уровней, кривая обучения и пропускная способность код-ревью входят в риск поставки.

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

6. Шестинедельный план технологического решения

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

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

• Записали критичные пользовательские задачи и пороги качества.
• Проверили матрицу целевых устройств и операционных систем.
• Испытали самый рискованный вертикальный срез на реальных интеграциях.
• Оценили объём платформенно-специфичной работы.
• Смоделировали стоимость сопровождения и лицензий на три года.
• Подготовили план выхода для данных, кода и бизнес-правил.
• Определили триггеры, которые вернут решение к пересмотру.

7. Границы и режимы отказа: инструмент не заменяет продуктовую стратегию

Самая частая ошибка — превращать долю общего кода в показатель успеха. Даже если общей окажется большая часть кода, критические проценты потребуют экспертизы по обеим платформам. Верно и обратное: раздельные нативные приложения без правильной модульности воспроизводят одну и ту же ошибку дважды. No-code стартует быстро, но с ростом нестандартных требований превращается в запутанную цепочку плагинов. Любой подход дорог, когда применён плохо.

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

Последняя граница — организационная. Технология без владельца устаревает даже при самой правильной архитектуре. Выбор должен падать на решение, которое команда способна развивать, тестировать, наблюдать и уверенно обновлять. Покупать модули, не несущие продуктовой дифференциации, и осознанно контролировать ключевую способность — обычно более сбалансированный подход к build vs buy.