Contact person: Business Client

Phone:Show

Email:Show

Location: Baramulla, India

Budget: Recommended by industry experts

Time to start: As soon as possible

Project description:
"# Project Brief — Child-Face Lock App (Android + iOS)

**Goal:**
A cross-platform parental app that detects a registered child’s face and immediately prevents that child from using a parent’s phone. When the child is detected, the device is locked or switched to a restricted safe-screen; parents can override quickly via PIN/biometrics.

---

# Key Requirements (MVP)

**Functional**

* Register one or more child face profiles (on-device).
* Continuously or periodically check front camera for a registered child when phone is in use.
* If registered child detected → trigger a lock / safe-screen that prevents normal phone use.
* Parental override: PIN or device biometric (FaceID/TouchID, Android biometrics).
* Audit log of detection events (time, photo thumbnail optional, kept locally).
* Basic parental dashboard: enable/disable, manage child profiles, viewing logs.

**Non-functional**

* Face recognition must run on-device (privacy + latency).
* Minimal battery and CPU impact.
* Robust against false positives/negatives.
* Secure storage of profiles and PIN (encrypted, Keystore/Secure Enclave).
* Respect platform rules & user consent; offer clear permission flows.

---

# Important Platform Constraints (must-read)

* **iOS:** Third-party apps cannot lock the entire device programmatically. Apple only allows device-level restrictions via **Guided Access** (user-enabled) or via **MDM/profiles** for supervised devices. App must use allowed alternatives: show a full-screen child-safe mode inside the app, guide parents to enable Guided Access, or pair with an MDM solution for stricter control.
* **Android:** More flexibility. Use **Device Admin / Device Owner (Kiosk/Lock Task)** modes or overlay + Accessibility services to restrict use. Note: Device Owner requires provisioning (works for single-purpose devices or with user consent during setup).

(Dev team: design flows accounting for these platform differences. iOS will need user education and/or a guided-access flow.)

---

# Suggested Architecture & Tech Stack

**Cross-platform UI**

* **Flutter** (recommended) or **React Native** (alternative)

**On-device ML / Face Detection**

* **TensorFlow Lite** (custom child-face recognition model) — offline, fast.
* **Firebase ML Kit** for face detection helpers (pose/landmarks) if acceptable.
* **Core ML** (iOS) and **ML Kit/TFLite** (Android) for optimized pipelines.

**Backend / Cloud (optional)**

* **Firebase** for user auth, remote config, optional cloud sync (but allow purely local mode).
* Use cloud **only** if parents want multi-device sync — otherwise keep profiles local for privacy.

**Storage & Security**

* **Android Keystore / iOS Secure Enclave** for PIN & credentials.
* Encrypted local DB (SQLCipher or encrypted Hive/SQLite).
* Store face embeddings, not raw images. If storing images, encrypt and explain to users.

**Permissions**

* Camera (foreground) — explain use-case clearly.
* Biometric authentication (for overrides).
* Accessibility / Usage Access / Device Admin (Android) — explain necessity.
* Local notifications (for parent alerts).

**CI / Testing**

* Firebase Test Lab (Android), TestFlight (iOS), unit + integration tests, device battery profiling.

---

# Detection Flow (high-level)

1. Parent registers child → capture multiple front-camera photos in guided flow (varied lighting/angles).
2. App computes face embeddings and stores them encrypted on-device.
3. When phone is active or unlocked, app performs periodic/triggered checks (not continuous video to save power).
4. If face embedding similarity > threshold → trigger lock/safe-screen.
5. Lock event logged; parent receives optional alert.
6. Parent overrides via PIN/biometric → session resumes.

---

# UX / UI Notes (for dev + design)

* Parent-facing screens must be minimal and explicit: setup wizard, permissions, test-scan, enable Guided Access instructions (iOS).
* Child-facing lock screen should be friendly and non-scary (cute message + animation), and must not reveal any sensitive info.
* Provide clear error/false-detect flow and “did we get it wrong?” correction UI to improve embeddings.
* Include an “emergency unlock” flow in case of false lock (quick biometric fallback).

---

# Privacy & Compliance

* Default: **on-device processing only**. Explicit opt-in required for any cloud sync.
* Collect minimal data. Store embeddings instead of images where possible.
* Provide clear privacy policy explaining what is stored, where, and for how long. Allow users to delete profiles.
* Consider GDPR/COPPA implications (app involving children) — consult legal before launch.

---

# Risks & Mitigations

* **False positives/negatives:** Provide retraining UI, adjustable detection threshold, multi-frame confirmation before locking.
* **Battery drain:** Use event-driven detection (e.g., detect only when phone is unlocked or when front camera in use) — avoid constant camera streaming.
* **Bypassing app:** Android: use Device Owner / Kiosk mode where feasible. iOS: require Guided Access or MDM for strict blocking.
* **Privacy backlash:** Default to local-only processing; transparent consent flow.

---

# MVP Roadmap & Sprints (suggested)

**Sprint 0 — Planning (1 week)**

* Finalize requirements, UX flows, permissions, legal check.

**Sprint 1 — Prototyping (2 weeks)**

* Flutter app skeleton, camera + onboarding UI, face capture flow.

**Sprint 2 — On-device Detection MVP (3 weeks)**

* Integrate TFLite/ML Kit for face detection, create embeddings, simple matching pipeline (local).

**Sprint 3 — Lock/Overlay Implementation (3 weeks)**

* Android: implement lock/task mode (kiosk) and overlay.
* iOS: implement full-screen safe-screen + Guided Access instructions.

**Sprint 4 — Security + Storage (2 weeks)**

* Implement encrypted storage, biometric override, logs.

**Sprint 5 — QA & Beta (2–3 weeks)**

* Tests, small-family pilot, battery/perf tuning.

**Sprint 6 — Launch Prep (2 weeks)**

* App Store / Play Store packaging, privacy policy, marketing screenshots.

*(Adjust timelines to team size; above assumes small cross-functional team.)*

---

# Deliverables for Developers

* Repository with modules: camera, ML, matching, lock/overlay, settings, logs.
* On-device model conversion (TFLite) + sample embeddings.
* Test suite + profiling reports (battery/CPU).
* Documentation: permissions rationale, iOS Guided Access setup guide for parents, and security summary.

---

# Team & Roles

* 1 Mobile Engineer (Flutter/React Native)
* 1 Native Android engineer (lock/task, device admin)
* 1 iOS engineer (Guided Access flows, CoreML integration)
* 1 ML Engineer (training model, TFLite optimization)
* 1 UX/UI Designer (setup flows, friendly lock screen)
* 1 QA/DevOps (CI, TestFlight/Firebase Lab)

---

# Quick Ask to Developer Team

* Confirm acceptance of platform constraints (iOS Guided Access vs MDM).
* Decide offline-only vs optional sync.
* Choose cross-platform framework (Flutter recommended).
* Estimate sprint allocation based on your dev capacity.

---

If you want, I can now:

* produce a 1-page technical spec PDF for your devs, or
* generate the onboarding UI wireframes (Flutter-ready), or
* write the README + GitHub repo scaffold." (client-provided description)