Tech Stack Blueprint — Ayla App (Ages 9–14)
Goal: Pick a stack that maximizes kid‑safety, fast iteration, creator ecosystem
readiness, and low total cost of ownership (TCO). Below is the recommended “happy
path,” with side‑by‑side comparisons and WHY each choice is optimal for this product.
0) Design Principles (drive every tech choice)
• Safety‑first: COPPA/GDPR‑K compliance; data minimization; on‑device processing where
possible.
• Active > passive: 60–90s micro‑games with immediate feedback, not video.
• Templateable: internal team ships fast with reusable templates; future creators fill forms/JSON,
not arbitrary code at first.
• Low friction: one app, both platforms, light downloads, works offline.
• Observability & iteration: A/B testing, feature flags, bandit‑style ranking.
1) Client Apps (Mobile Shell + Game Runtime)
Recommendation (MVP → Scale)
• App Shell/UI: Flutter (Dart)
• In‑App Game Runtime: HTML5 + WebView (sandboxed) for micro‑games; Flutter Flame for
select native 2D templates.
WHY this combo
• Flutter gives consistent 60fps UI, excellent text rendering, and fewer device‑specific layout bugs
vs RN. Your team ships a single codebase with near‑native perf.
• HTML5 micro‑games enable a future creator ecosystem (most creators know JS/Canvas). We
sandbox each mini‑game inside a tightly locked WebView and expose a tiny JS bridge for scoring
& telemetry.
• Flutter Flame covers any templates that need ultra‑tight loops (e.g., tracing shapes with CV
overlay) without WebView overhead.
Alternatives & tradeoffs
Option Pros Cons Verdict
RN perf sensitive to JS thread; Viable, but Flutter’s
React Native Huge dev pool; JS
extra native modules for rendering is steadier for
+ WebView everywhere
drawing; text perf quirks kid‑grade devices
Heavy runtime; slow UI
Game
Unity for the iteration; harder app‑like Overkill for micro‑games
powerhouse;
whole app screens; larger bundle; creator and feed UX
physics & tools
web tooling harder
1
Option Pros Cons Verdict
All‑native
Max control; best Two codebases; slower Not optimal for startup
(Swift/
perf iteration; harder to staff speed
Kotlin)
Key packages/components (Flutter)
• UI: Material 3 + custom theming, animations (Implicit/Explicit), Lottie for confetti/rewards.
• Web Runtime: webview_flutter with hardened settings (JS on, but no file:// access,
blocked navigation, strict allowlists, CSP headers, no eval).
• 2D Native Games: Flame engine (sprite animation, input, audio).
• Local DB/Cache: sqflite or drift for structured storage; shared_preferences for tiny
flags.
• Media: camera via camera plugin; image/video processing via on‑device (see §5).
• Accessibility: semantic labels, scalable text, high‑contrast theme toggle.
Game packaging model
• HTML5 pack (zip or versioned folder on CDN) → loaded into WebView origin
[Link] → PostMessage/JS bridge for: start , score , complete ,
telemetry , ageBand (no PII). All outbound links blocked.
• Template SDK (Phase 1 internal): JSON schema per template (e.g., Fraction Flick) → renderer
either HTML5 or Flame.
2) Backend Core (Auth, Data, APIs, Realtime)
Recommendation (Primary)
• Cloud: Google Cloud + Firebase
• Auth: Firebase Authentication (email/passwordless for parents, device‑bound for kids),
optional Apple/Google sign‑in for guardian.
• Data: Firestore (profile/settings, progress shards) + Cloud Storage (assets) + Cloud Functions/
Run for business logic.
• Analytics: BigQuery export + Firebase Analytics (with child‑safe config).
• Remote Config & A/B: Firebase Remote Config + A/B Testing.
WHY
• Tight integration reduces glue code; family‑policy friendly; first‑class offline support (Firestore
local cache). Push (FCM), Test Lab, and ML Kit are adjacent wins.
Alternatives & where they fit
Stack Pros Cons Use when
No built‑in push; you If you want SQL +
Supabase SQL power; great for
manage analytics self‑host control; can
(Postgres + relational content;
export; auth flows combine with Firebase
Realtime) row‑level security
need COPPA care Auth (custom tokens)
2
Stack Pros Cons Use when
AWS (Amplify/
Setup complexity; If you’re already
Cognito + Enterprise‑grade;
kid‑app analytics not AWS‑native or require
Dynamo/ fine‑grained IAM
turnkey VPC/private networking
Aurora)
Custom Node/
More dev ops; reinvent Later stages with a
Nest + Full control, portable
wheels (auth, A/B) larger platform team
Postgres
Data model sketch
• users_guardians (guardian account, email verified)
• users_kids (pseudonymous, linked to guardian)
• devices (device fingerprints, permissions)
• skills (taxonomy tags)
• game_templates (id, type, schema, version)
• game_packs (HTML5 bundles metadata)
• quests (curated sequences)
• plays (kid_id, game_id, outcome, time_spent, skill_tags) → append‑only
• feedback_reports (moderation)
Minimize PII: for kids, store only age band & coarse locale; keep phone/email exclusively
on guardian record.
3) Personalization & Ranking
MVP
• Contextual multi‑armed bandit (Thompson Sampling): features = age band, recent success
rate by skill, game dwell time, skip rate.
• Storage in Firestore; daily batch in Cloud Functions; feature flags via Remote Config.
Phase 2
• Embeddings + vector search for semantic similarity between games/skills.
• Option A: Cloud SQL (Postgres) + pgvector for low‑ops simplicity.
• Option B: Managed vector DB (Pinecone/Weaviate) if scale/ops justify.
WHY not deep RL now
• Bandits converge quickly with sparse data and are interpretable for parents/regulators. We
avoid opaque black‑box “algorithms” early.
3
4) Content Pipeline (Internal & Creator)
Internal authoring (Phase 1)
• Web Admin App: React ([Link]) + TypeScript; hosted on Vercel/Cloud Run.
• Template Studio: form‑based editors that emit validated JSON against each template schema;
preview via embedded WebView/Flame.
• Validation: Zod/JSON Schema validation; spell‑check; profanity blocklist.
Creator beta (Phase 3)
• Submission: upload HTML5 bundles built with Phaser or PixiJS; we provide SDK with: lifecycle
hooks, scoring API, content limits.
• Sandboxing: subdomain per game, CSP ( default-src 'self' ), no third‑party scripts, max
asset size, no network policy by default.
• Moderation workflow: automated checks (static scan for PII prompts, profanity, trackers) →
human review → limited rollout bucket → full release.
WHY HTML5 for creators
• Lowest barrier to entry, broadest talent pool, fast iteration, and easy sandboxing with WebView.
Native plugins are not allowed in creator phase to preserve safety.
5) Safety, Privacy, and On‑Device ML
Camera tasks (opt‑in)
• On‑device face detection & blur: MediaPipe/ML Kit → real‑time blur or mosaic. No biometrics
stored.
• Local‑first media: default local storage only; explicit guardian opt‑in before any upload.
• Non‑camera alternative surfaced by Remote Config rule.
Text & asset moderation
• Client‑side filters: blocklist for text inputs; lightweight on‑device toxicity (e.g., Distil models via
TFLite if needed).
• Server checks: content scanning on upload; checklists for PII/questions; image nudity detection
models running on Cloud Run.
Compliance guardrails
• Age gating; verifiable parental consent for U13.
• No behavioral ads; contextual only; frequency‑capped.
• Data retention windows; export/delete mechanisms in guardian portal.
4
6) Ads & Monetization
Free tier (contextual ads only)
• Networks: Google AdMob (Family program) + kid‑safe partners (e.g., SuperAwesome) for
stricter compliance.
• Placement rules: never in camera/assessment moments; only between cards; clear “Ad” label;
capped impressions/session.
Premium
• Mobile IAP: Apple IAP + Google Play Billing for Family Premium (ad‑free, quests, language
packs).
• Web Parent Portal: Stripe Billing for family plan management and email‑first login, mapped to
Firebase Auth via custom claims.
WHY this combo
• App‑store compliance + web flexibility for guardians; contextual ads reduce legal risk; Stripe for
clean recurring logic outside app stores when needed.
7) Analytics, Experimentation, and Metrics
• Product analytics: Firebase Analytics (kids‑mode), export to BigQuery for modeling DALM and
mastery curves.
• Feature flags/A‑B: Firebase Remote Config or ConfigCat/LaunchDarkly if you need multi‑env
governance.
• Crash/Perf: Sentry (Flutter SDK) + Firebase Performance for network & render traces.
• Privacy: never log raw text answers; only outcomes/skill tags; coarse timestamps.
8) Search & Discovery
• In‑app search: Algolia (synonyms, typo‑tolerance) or OpenSearch/Elasticsearch if self‑hosting;
index quests, skills, and tags.
• WHY Algolia now: quickest to great results, good analytics, low ops. Migrate to self‑hosted if
cost scales.
9) Notifications & Scheduling
• Push: Firebase Cloud Messaging (bridged to APNs on iOS). Topics per age band/quest.
• Local nudges: client‑side schedule that respects guardian time windows; break‑friendly design.
• Email (guardian): Transactional via Postmark/SendGrid; weekly digest renderer via Cloud Run.
5
10) Offline & Performance Strategy
• Install size budget: < 80MB initial; micro‑games fetched on demand.
• Asset strategy: image spritesheets, vector where possible; audio in short OGG/AAC clips; shared
asset packs cached.
• Offline: Firestore cache + SQLite mirrors of progress; queued telemetry with retry; background
prefetch of tomorrow’s quest.
11) DevOps, CI/CD, and Environments
• CI/CD: GitHub Actions → build Flutter (Android/iOS) + run tests + upload to stores via Fastlane.
• Device testing: Firebase Test Lab (physical fleet) for top 10 devices.
• Environments: dev (internal), beta (TestFlight/Play Internal), prod . Remote Config keys
per env.
• Observability: Sentry + Health endpoints on Cloud Run; uptime monitoring via Cloud
Monitoring.
12) Security Hardening Checklist
• WebView: disable file access, mixed content, JavaScript dialogs; intercept and block external
navigation; set CSP; isolated origins; no cookies shared with app.
• Network: all endpoints behind HTTPS + WAF; signed URLs for asset fetch; short‑lived auth
tokens.
• Storage: encrypt at rest; client secure storage for tokens; key rotation policy.
• RBAC: least privilege for admin tools; audited actions; separate prod/stage projects.
• Supply chain: Dependabot + lockfiles; 3rd‑party license scan.
13) Team Topology & Ownership
• Mobile team (Flutter): shell, feed UX, WebView bridge, Flame templates.
• Game Content team: HTML5 templates (Phaser/Pixi), art/audio.
• Backend: Firebase rules, Cloud Functions/Run, data modeling, ranking jobs.
• Safety & QA: moderation tooling, model thresholds, test lab, accessibility.
• Data: analytics pipelines (BigQuery), metrics, A/B test design.
14) Cost Posture (lean start, elastic scale)
• Firebase free/low tiers carry MVP; BigQuery costs controlled by table partitioning; HTML5
games on Cloud Storage + CDN are cheap; no always‑on servers.
• Heavy GPU inference avoided by on‑device ML; server models only for moderation bursts.
6
15) Roadmap Tie‑In (from Product Plan)
• Phase 1 (MVP): Flutter shell + WebView runtime, 6–8 templates (mix HTML5/Flame), Firebase
core, contextual ads, FCM, Remote Config, bandit v1.
• Phase 2: Quests/offline packs, parent digest emails, accessibility options, BigQuery mastery
modeling, Algolia search.
• Phase 3: Creator SDK (HTML5), submission portal, moderation queue, marketplace payment
rails.
16) Concrete “Starter Kit” (no code, just components to install
Day 1)
• Flutter stable; webview_flutter , flame , sqflite , sentry_flutter , firebase_*
packages (auth, firestore, storage, analytics, messaging, remote_config, performance), intl
for i18n.
• Web game starter: Phaser 3 template with our JS bridge stub.
• Backend: Firebase project (Auth providers on; Firestore rules; Storage rules), Cloud Functions
skeleton, BigQuery export enabled.
• Ops: GitHub Actions CI, Fastlane lanes, Sentry DSN, Test Lab matrix.
17) FAQs & “Why not X?”
• Why not Unity for micro‑games? Heavier bundles, slower feed/UI iteration, harder to sandbox
3rd‑party games safely; HTML5 in WebViews is easier to audit & version.
• Why not pure RN? It’s fine, but Flutter’s renderer avoids JS‑thread jank and ships more
predictable typography & layout across low‑end Androids common in our markets.
• Will WebView be too slow? For 2D, low‑asset HTML5 games with capped draw calls, it’s perfectly
fine. Reserve Flame for the few needs that demand tighter loops.
• SQL vs Firestore? Firestore wins for offline‑first progress & feed latency; if/when relational
queries grow, add Cloud SQL for reporting/joins—hybrid is common.
• Do we need a vector DB now? Not for MVP; add pgvector after you have thousands of games
and real embedding features.
18) One‑Page Architecture (textual)
Flutter App (Feed, WebView, Flame) ⇄ Firebase Auth ⇄ Firestore (profiles, plays, configs) ⇄ Cloud
Functions/Run (ranking jobs, moderation checks) ⇄ Cloud Storage + CDN (game bundles) ⇄
BigQuery (analytics) ⇄ Remote Config / A‑B (experiments). Optional: Cloud SQL + pgvector (Phase 2),
Algolia (search), Stripe (web guardian billing).
7
Final Word
This stack is tuned for a kid‑safe, creator‑ready, fast‑iterating product. It lets a small team ship a
polished MVP quickly, measure Daily Active Learning Minutes, and scale toward a moderated creator
marketplace—without painting you into a platform corner.
