Потрібен спеціаліст з досвідом публікації додатків в Google Play

Розробка міжнародного мобільного додатку під ключ (Дизайн + Код) Для здешевлення, можливо не робити в купити готовий дизайн 1. Загальні вимоги до проекту Платформа: Кросплатформова розробка на фреймворку Flutter (один код під iOS та Android). Тип платформи: Соціальний беттінг / Ігрові суперечки на дисципліну (Peer-to-Peer 도전戰). Завдання Виконавця: Повний цикл розробки (UI/UX Дизайн у Figma, фронтенд, бекенд-сервер, база даних, інтеграція IoT-датчика контролю та платіжного шлюзу). Мультимовність: Повна підтримка локалізації (i18n) та робота з кількома валютами. 2. Вимоги до UI/UX Дизайну Потрібна розробка сучасного, неоново-технологічного інтерфейсу в темних тонах (Dark Mode). Акцентні кольори: Глибокий графітовий (фон), яскравий зелений (фінанси, баланс), яскравий червоний (режим охорони включень, штрафні події). Функціонал: Відображення 4 головних екранів нижньої навігації (Дашборд, Ігрові кімнати, Гаманець, Налаштування пристрою). Потрібні динамічні анімації зміни балансу та спливаючих алертів. 3. Фінансова архітектура (Escrow/Holding/Split) Додаток пов'язань на утримання депозитів за дотримання правил дисципліни. Критично важливою є інтеграція платіжного шлюзу, що підтримує Split Payments (Розщеплення платежів) та Холдування коштів (Stripe Connect для глобального ринку/аналоги для локального). Логіка транзакцій (API-команди бекенда): Поповнення: Кошти користувачів прив'язуються до їх облікового запису та заморожуються на транзитному (ескроу) рахунку платіжної системи. Вони не надходять безпосередньо на рахунок компанії. Режим SOLO: При настанні тригерної події від IoT-датчика у заборонених годин бекенд дає команду платіжній системі перевести фіксовану суму (штраф) з транзитного рахунку користувача на розрахунковий рахунок компанії. Режим GROUP (Кімнаті): Користувачі формують загальний пул (наприклад, 10 осіб $10). Гроші заморожуються у межах конкретної Ігрової Кімнати. При настанні тригерного події в одного з учасників сума його штрафу автоматично розщеплюється: 15% (комісія платформи) йдуть на розрахунковий рахунок компанії, а 85% залишаються усередині призового фонду кімнати. Після закінчення терміну челенджа бекенд автоматично розподіляє нагромаджений призовий фонд між переможцями, а платіжна система робить автоматичний переказ (Payout) ним на картки. 4. Структура кабінетів Кабінет 1: "Персональний Трекер" (Режим SOLO) Індикатор статусу моніторингу (Активний/Доступний/Заблокований). Конфігуратор часових інтервалів охорони (Time Picker) та налаштування вартості штрафного тригера. Панель стану зовнішнього пристрою IoT (заряд батареї датчика у %, рівень сигналу, статус синхронізації). Кабінет 2: «Ігрові Кімнати» (Режим GROUP) Інструментарій створення приватних кімнат (генерація інвайт-посилань/кодів для друзів) та список публічних глобальних ліг. Турнірна таблиця (Лідерборд) учасників з відображенням їхнього поточного статусу в реальному часі, таймер до кінця челленджа та вбудований груповий чат. Загальний розділ: Мультивалютний гаманець Відображення балансу з автоматичним конвертуванням локальних валют у реальному часі. Історія транзакцій із прозрачним логом списань, комісій та виграшів. 5. Вимоги до Бекенду та Інтеграції IoT Стек: Node.js/Python/Go (на вибір виконавця, аргументовано). Зв'язок із IoT: Прийом пакетів даних від зовнішнього Wi-Fi модуля. Швидкість надсилання Push-повідомлення (через FCM) на смартфон при настанні події від датчика – менше 1 секунди. Антифрод-логіка: Сервер повинен аналізувати передані датчиком телеметричні дані вбудованого акселерометра (accel_x/y/z). Якщо подія відбувається при нульовій зміні осей прискорення, транзакція позначається системою як підозрілий (захист від статичного утримання датчика), користувачеві надсилається попередження.

дзвінки здійснюються через SIM-карту на iPhone, то потрібно автоматично передавати інформацію про вхідні/вихідні дзвінки в CRM