Не переписувати все. Запустити, виміряти й виносити в native лише те, що реально впливає на retention і revenue.
Це соціальна discovery-платформа з подіями, сторісами, чатами, гаманцем, монетами, рефералкою, KYC, бізнес-акаунтами та публічними сторінками.
П'ять бізнес-моделей одночасно роблять продукт технічно й регуляторно складнішим, ніж класична dating-апка. Це головна причина обережності з повним переписуванням.
push, камера, медіа, Apple / Google / Facebook login, payments, face verification, deep links, sharing.
більшість екранів, навігація, профілі, stories, events, referral, admin- і business-флоу.
Висновок: додаток уже існує для iOS та Android. Переписувати фундамент не потрібно — потрібно його посилити.
Чим «гостріший» блок — тим більше в ньому логіки, медіа й ризику, і тим обережніше з його переписуванням.
Це дорого, довго і ризиковано. Правильний шлях — еволюція, а не революція: залишити hybrid, оптимізувати його, запустити продукт, зібрати реальні дані, а потім точково виносити найважчі модулі в Flutter-native.
Це не 10–20 екранів, а ціла платформа з ролями, флоу й інтеграціями.
4–8 місяців на rewrite — і ринок так і не перевірено.
Без DAU/MAU, retention і реальних метрик rewrite — це здогадка.
Swift + Kotlin + Web: кожна фіча коштує дорожче й довше.
App/Play review, payments, UGC-модерація, KYC — терміновіші ризики.
Запустити, привести users, перевірити events, чати й payments. Native — точково, де він впливає на engagement або revenue.
Поточна Flutter + Angular WebView app лишається базовою production-версією. Заморозити ідею повного rewrite.
Знайти реальні bottlenecks, відділити відчуття від фактів: performance, WebView, media, payments, compliance, analytics.
Media й caching, lazy loading, skeletons, стабільна навігація, memory, fallback для поганого інтернету, feature flags.
Перші реальні події й партнери. Funnel: реєстрація → профіль → подія → чат → payment → retention.
Лише найважчі UX-модулі у Flutter-native — там, де native дає вимірюваний impact.
Pure Swift/Kotlin — лише пізніше, за сильного traction, revenue і команди для підтримки трьох кодових баз.
80–90% — Angular WebView.
10–20% — Flutter-native критичні екрани.
Не вся апка переписується. Технологія островів — Flutter / Dart, бо shell, build pipeline і bridge уже є. Один код на iOS і Android.
Media-heavy UX зі swipe, анімаціями, gifts і paid unlock — тут різниця між WebView і native найпомітніша, а вплив на engagement і revenue найбільший. Далі: Event Feed → Profile Discovery → Chat → Camera/Media.
Angular WebView лишається основою, Flutter — native-інтеграції. Найшвидший шлях до запуску, одна кодова база.
Більшість app — web, найважчі модулі — Flutter-native. Точково покращує UX, не вбиває roadmap, зберігає одну mobile-базу.
Весь mobile UI у Flutter, web окремо. Кращий UX, одна mobile-база, дешевше за Swift+Kotlin — але великий scope.
Окремо iOS і Android, web окремо. Максимальна якість — але 3 кодові бази, дорожча команда, довший time-to-market.
Усе digital всередині app: coins, premium, paid stories, gifts із digital benefit, boosts, unlock.
Реальні offline-події, реклама ресторанів і клубів, lead generation для бізнесу.
Виведення creator-балансу. На старті — manual payouts лише після KYC.
GetStream cost перевищує власну infra + команду, і є стабільні 50–100k+ active users.
Потрібні: сильний backend, 24/7 support, moderation/fraud-команда і чітка стратегія міграції даних. До того — GetStream.
Для App Store, Google Play, PSP і рекламних платформ продукт має звучати як events-based social discovery — verified profiles, curated experiences — а не adult/escort-marketplace.
Це збігається з продуктовим баченням команди: ставка на живий, якісний контент і реальні зустрічі, а не на приватний платний контент.
Оцінки орієнтовні, без доступу до коду. Після audit їх потрібно уточнити.
Не переписувати платформу зараз. Запустити, довести цінність, виміряти проблеми — і переписувати тільки те, що реально впливає на retention, revenue або довіру.