До 60% заявок на гранты для мобильных игр отклоняются на этапе технической экспертизы из-за поверхностного описания стека, где Jetpack Compose указан как «модный фреймворк», а не инструмент оптимизации разработки. Эксперты фонда ищут подтверждение масштабируемости, а не простое перечисление библиотек.
Ошибка в описании State Management и рекомпозиции
Типичный провал: описание архитектуры как «набора экранов на Compose». Для грантодателя это сигнал о низком уровне компетенций. В играх, где частота обновления кадров критична, отсутствие упоминания StateFlow, SharedFlow или управления состоянием через ViewModel ведет к вердикту «нестабильное решение». Если вы не прописали, как избегаете лишних рекомпозиций в динамических интерфейсах игры, эксперт заложит риск падения FPS до 30-40% на бюджетных устройствателях.
Кейс: Проект с заявленным бюджетом в 2 млн руб. был отклонен, так как в техчасти было указано «использование стандартных переменных для обновления UI». Правильный подход — обоснование использования Unidirectional Data Flow (UDF), что сокращает время на отладку интерфейса на 20-25% и гарантирует консистентность данных.
Вывод: Описывайте не «что используете», а «как управляете состоянием». Без UDF проект выглядит как любительский прототип.
Игнорирование жизненного цикла и ресурсов памяти
Многие стартапы забывают указать, как Compose взаимодействует с тяжелыми игровыми ресурсами. Ошибка в том, чтобы не описать интеграцию с Canvas или использование Side-effects (LaunchedEffect, DisposableEffect) для управления жизненным циклом аудио-движка или сетевых соединений. В результате заявка выглядит так, будто приложение «съест» всю оперативную память (от 500 МБ до 1.2 ГБ на простых сценах) из-за утечек памяти в композициях.
Пример: Сравнение подхода «все в одном экране» против «модульной навигации». Первый вариант увеличивает время холодного старта приложения на 1.5–3 секунды, что критично для удержания пользователей (Retention Day 1 падает на 5-10%). В заявке нужно четко прописать стратегию ленивой загрузки компонентов.
Вывод: Обязательно включите раздел по оптимизации производительности Kotlin-приложений как фактор конкурентоспособности при подаче на грант, иначе проект сочтут технически сырым.
Поверхностное обоснование связки Compose и Firebase
Ошибка: фраза «Firebase будет использоваться для базы данных». Это пустая формулировка. Эксперты ищут конкретику: почему выбрана Firestore вместо Realtime Database для конкретных игровых сущностей. Если вы не обосновали выбор NoSQL структурой данных (например, иерархией профилей игроков и их инвентаря), заявку могут отклонить из-за «необоснованного выбора технологического стека».
Мини-кейс: Стартап запрашивал 3 млн руб., указав Firebase без схемы синхронизации. Эксперт задал вопрос о стоимости чтения/записи при 10 000 DAU. Отсутствие расчета стоимости операций (в диапазоне $0.06 за 100к чтений в Firestore) показало, что команда не считает юнит-экономику облачных затрат.
Вывод: Firebase в грантовых заявках: как обосновать выбор NoSQL и Realtime Database для масштабирования игры — это должен быть отдельный расчетный блок с цифрами нагрузки.
Отсутствие стратегии тестирования декларативного UI
В традиционном XML-подходе тесты понятны. В Compose требуется описание Semantic Tree и использования Compose Test Rule. Если в разделе «Контроль качества» указано просто «ручное тестирование», вероятность отказа возрастает. Грантодатель хочет видеть автоматизацию, которая сократит цикл релиза с 14 до 7 дней.
Статистика: Внедрение UI-автотестов на Compose снижает количество критических багов в продакшене на 30-45% по сравнению с ручным тестированием. Отсутствие этого пункта в техзадании говорит о том, что команда не готова к масштабированию продукта.
Вывод: Без описания автоматизированного тестирования UI проект считается рискованным с точки зрения сроков реализации и качества.
Вывод
Чтобы избежать отказа, перестаньте описывать стек как список инструментов. Начните с внедрения жесткой архитектуры UDF, детального расчета стоимости операций в Firebase и стратегии оптимизации рекомпозиций. Избегайте общих фраз о «современности» Kotlin; вместо этого сфокусируйтесь на подготовке технической документации для IT-гранта: спецификации на Jetpack Compose и архитектура приложения, где каждый технический выбор подкреплен цифрой по производительности или стоимости. Только такой подход переводит заявку из категории «идея» в категорию «инженерный проект».