# Usalama Immediate Roadmap And Technical Analysis

**Current stage:** investor MVP demo.  
**Last UX hardening update:** June 13, 2026.  
**Safety boundary:** Usalama helps children alert trusted adults faster during high-stress situations. It is not a live emergency service, does not guarantee delivery or rescue, and does not replace `911`, emergency services, law enforcement, direct adult supervision, or professional monitoring.

## 1. Product Definition

Usalama is a parent-managed Safety Circle response workflow. The pilot should prove one narrow assumption: a child or vulnerable person can instantly notify trusted responders from a phone without navigating through the device during an emergency.

Public claims should stay narrow: Usalama helps children alert trusted adults faster during high-stress situations. It should not be marketed as saving a child, preventing harm, guaranteeing rescue, or replacing emergency services.

After SOS dispatch starts, Usalama requests one current position and attaches a map pin if available. SOS does not wait for geolocation. The MVP does not watch movement or request background location. Call-child and call-emergency-services actions are visible response supports, not guarantees. A pilot-only, visible setting can request a 5-second emergency audio context clip after dispatch begins. Audio capture is never hidden and never blocks SOS.

## 1A. Pilot Focus

**Primary objective:** prove that parents trust the Safety Circle model and that trusted responders acknowledge and act when an alert occurs.

### Pilot roles

- Parent: creates the account, manages children, manages Safety Circle.
- Child: triggers alert and checks in safe.
- Admin: manages the pilot and support workflow.

### Core workflow

1. Parent setup: name, phone, email.
2. Child setup: name, age, device.
3. Safety Circle setup: parent, second parent, grandparent, neighbor, teacher or other trusted adult.
4. Emergency activation captures timestamp and best-available location.
5. Safety Circle receives child name, time, location, open-map action, call-child action, and acknowledge-alert action.
6. Escalation expands from parent to backup responders to the full Safety Circle if acknowledgement is delayed.
7. Safe check-in sends a simple non-emergency status message to the parent.

## 2. Current MVP

| Area | Current capability |
| --- | --- |
| Activation | Three-second SOS hold, accidental-trigger cancel window, and protected account changes |
| Safety Circle | Small trusted-responder groups with parent-priority and backup escalation |
| Emergency UX | Automatic dispatch with no recipient selection, visible SOS state steps, locked safety-critical modals, acknowledgement-oriented delivery, escalation, and parent response action demos |
| Incident API | Local Node API and deployed Netlify Function |
| Delivery model | Safety Circle escalation-group summary with simulated `accepted -> sent -> delivered` states |
| Duplicate protection | Idempotency key per incident |
| Privacy | One SOS pin request only; no continuous tracking; pilot-only 5-second audio context clip off by default |
| Public launch surface | Branded homepage, progressive-disclosure parent/pilot and investor/partner forms, audience-specific thank-you pages, and custom HTTPS domain |
| Operations | Netlify Forms lead capture, branded signup document packet, and a credential-gated Phase 0 staff dashboard with live/manual/planned status labels |
| Hosting | Live Netlify investor demo at `https://usalamasafety.com` |

## 3. Architecture

### Investor MVP

```mermaid
flowchart LR
  A["PWA"] -->|"Three-second SOS"| B["Netlify Function"]
  B --> C["Signed demo incident token"]
  B --> D["Simulated list delivery progress"]
  D -->|"Poll status"| A
```

### Closed pilot

```mermaid
flowchart LR
  A["PWA and later native apps"] -->|"Authenticated SOS"| B["API gateway"]
  B --> C["Incident service"]
  C --> D[("Managed encrypted database")]
  C --> E["Job queue and messaging worker"]
  E --> F["SMS provider"]
  F -->|"Signed callback"| G["Webhook handler"]
  G --> D
  C --> H["Audit and observability"]
```

### Production data model

| Entity | Purpose |
| --- | --- |
| `users` | Verified account owner |
| `devices` | Registered device sessions and credentials |
| `response_groups` | Parent-priority, backup, and full-circle escalation groups |
| `recipients` | Verified opt-in Safety Circle responders and group memberships |
| `incidents` | One SOS lifecycle with idempotency key |
| `deliveries` | One provider attempt per recipient and channel |
| `audit_events` | Security-relevant actions and access review |

## 4. Immediate 30-Day Roadmap

### Week 1: Product and risk boundary

- Approve tracking-free product requirements and non-goals.
- Define pilot cohort, support model, and Safety Circle size limit. Keep early circles small enough to verify human response quality.
- Run legal, security, and safeguarding threat-model workshop.
- Define guardian opt-in, removal, anti-harassment, and dispute-handling rules.
- Conduct parent, teen, and youth-program interviews.

### Week 2: Hosted backend foundation

- Create development and staging environments.
- Add managed PostgreSQL schema and migrations.
- Build authenticated APIs, rate limits, request IDs, and audit events.
- Implement response groups, recipient memberships, and incident idempotency.
- Add logging, error tracking, uptime checks, backups, and restore testing.

### Week 3: Real-message integration

- Verify owner phone and recovery method.
- Build recipient invitation, acceptance, and removal.
- Integrate SMS provider adapter.
- Verify signed provider callbacks.
- Add retries, failure messaging, provider limits, and anti-spam controls.
- Test supported pilot-region provider coverage.

### Week 4: Controlled pilot readiness

- Run Safety Circle response drills at the approved pilot size.
- Test delayed, failed, and duplicate messages.
- Complete manual device matrix and accessibility pass.
- Approve legal language, support runbook, and incident-response process.
- Hold cross-functional go/no-go review.

## 5. Phases

### Phase 0: Investor MVP

**Status:** complete.

- Live Netlify demo.
- Branded public homepage on the secure custom domain.
- Netlify Forms for parent/pilot and investor/partner interest.
- Signup request packets with parent/pilot, investor/advisor, privacy/safety, roadmap, misuse, and technical-spec documents.
- Form redirects to audience-specific thank-you pages that make the correct documents immediately available.
- Credential-gated Phase 0 admin dashboard for launch operations.
- Three-second SOS hold.
- Visible SOS state progression: ready, holding, cancel window, dispatching.
- Automatic preconfigured Safety Circle dispatch.
- Tight Safety Circle demo with parent-priority and trusted-backup escalation groups.
- Demo incident modal now includes response actions for **Call child**, **Call emergency services**, and **Resolve** while preserving emergency-service disclaimers.
- App accessibility hardened for switch labels, remove-button labels, focus-visible states, and modal focus handling.
- Homepage lead forms now use progressive disclosure for optional details while preserving Netlify Forms capture.
- Continuous tracking removed; one emergency pin update allowed after dispatch.
- MVP product decision captured: pin drop + high-urgency alert + call actions.
- Pilot add-on modeled: optional 5-second audio context clip, off by default, captured only after dispatch starts, and never allowed to delay SOS.

### Phase 1: Closed technical pilot

**Estimated duration:** 6-10 weeks.

- Verified accounts and recipient opt-in.
- Hosted encrypted database.
- Real SMS callbacks, retries, limits, and monitoring.
- Per-responder delivery, acknowledgement, and escalation records.
- Pilot-region provider coverage validation.
- Security, legal, privacy, and safeguarding review.

### Phase 2: Native supervised beta

**Estimated duration:** 10-16 additional weeks.

- Native iOS and Android apps.
- Secure storage, MFA, device binding, login alerts, and rapid revoke.
- Push plus SMS fallback.
- Evaluate encrypted 5-second audio context delivery with consent, short retention, and abuse review.
- External penetration test and staged rollout.

### Phase 3: Limited launch

- Carefully defined segment and geography.
- Production support coverage.

## 6. Pilot Release Gates

The detailed [misuse prevention plan](./MISUSE_PREVENTION_PLAN.md) is mandatory. The pilot cannot proceed until its closed-pilot controls are implemented, tested, and reviewed.

| Gate | Evidence |
| --- | --- |
| Claims | Counsel approval; no rescue, guaranteed-safety, law-enforcement, or `911` replacement claims |
| Identity | Verified owner, recovery, and registered device sessions |
| Recipient consent | Verified opt-in and immediate removal |
| Messaging | Signed callbacks, retries, outage handling, throughput tests |
| Privacy | SOS-only pin capture, short retention, encrypted records, managed secrets |
| Pilot waiver | Parent consent, beta-software acknowledgement, emergency disclaimer, data request path, and abuse-prevention acknowledgement |
| Abuse prevention | Rate limits, MFA, audit logs, anti-spam controls, rapid revoke |
| Safety Circle delivery | Verified guardian opt-in, provider coverage, throughput, and abuse review |
| Operations | Monitoring, backups, restore test, support runbook, named responders |

## 7. Metrics

- SOS completion rate.
- Dispatch acceptance latency.
- Recipient delivery latency and failure rate.
- Duplicate-alert prevention.
- Cancellation and false-alert rate.
- Provider throughput at the approved Safety Circle size.
- Supported-region delivery outcomes.
- Crash rate.
- Pilot retention and user trust.

## 8. Founder Decisions

- Confirm the first parent-child supervised pilot cohort and geography.
- Approve Safety Circle size limits for the supervised pilot.
- Select SMS provider and supported countries.
- Choose safety advisor, security engineer, and legal counsel.
- Define support hours, escalation ownership, investor ask, and runway.

## 9. Parent-Child MVP Gap

The [MVP scope audit](./MVP_SCOPE_AUDIT.md) is the current implementation checklist. The investor demo proves the trigger, automatic dispatch, one-time pin, delivery-state UI, response-action concept, and resolution concept. The next MVP build must add:

- Verified parent account and consent.
- Linked child profile and child device.
- Verified Safety Circle opt-in and revoke.
- Real notification delivery with SMS fallback.
- Verified production parent incident actions: **Call child**, **Call emergency services**, and **Resolve incident** with server-side action records.
- Minimal incident history, location-access logs, and parent-facing deletion controls.

Constant tracking, route history, safe-zone geofencing, open chat, social features, AI threat detection, school district tools, and police integration remain outside the MVP.

## 10. Admin And Enterprise Backend Roadmap

The current dashboard is appropriate for landing-page operations, lead capture, launch notes, and investor-demo access. It is not yet the production control plane for a child-safety application.

### Current Capability Versus Production Need

| Layer | Current status | Production requirement |
| --- | --- | --- |
| Public website | Working on Netlify with custom HTTPS domain | Maintain with monitored deployments and approved content |
| Lead capture | Netlify Forms | Central CRM, consent status, segmentation, follow-up ownership |
| App users | Demo credentials only | Individual verified accounts, MFA, recovery, and revocation |
| Parent, child, and Safety Circle data | Demo data only | Encrypted production database and strict role permissions |
| Admin controls | Phase 0 launch dashboard with honest live/manual/planned labels | Role-based actions, approvals, support workflows, and audit logs |
| Security records | Demo API gate and limited logs | Immutable audit events, suspicious-access alerts, and review tooling |
| Backups and recovery | Not production-ready | Automated backups, restore testing, and disaster-recovery plan |
| System health | Manual checks | API, database, SMS, push, queue, and uptime monitoring |

### Phase 0: Launch Operations

```text
Cloudflare DNS
↓
Netlify Website
↓
Netlify Forms
↓
Manual review, export, and follow-up
```

This is sufficient for the public website, waitlist, pilot interest, investor interest, and early outreach. Netlify Forms must not become the database for parent, child, device, Safety Circle, or incident records.

Current signup-document delivery is immediate on-page access after form submission. Automated email delivery requires connecting Netlify Forms to an email/CRM provider such as Zapier, Make, HubSpot, Airtable, Mailchimp, Beehiiv, Postmark, SendGrid, or Resend.

### Phase 1: Pre-MVP Operating Backend

Connect the existing forms to a central contact and communications workflow:

```text
Netlify Forms
↓
Zapier or Make
↓
Airtable or HubSpot
↓
Mailchimp, ConvertKit, or Beehiiv
```

Required contact segments:

- Parent or guardian.
- Youth organization or pilot partner.
- Investor.
- Advisor: legal, privacy, security, safeguarding, or technical.
- Technical partner.
- Media.
- Community supporter.

Required operating controls:

- Record consent source, consent version, and unsubscribe status.
- Assign an owner and next follow-up date.
- Track contact-to-meeting, meeting-to-pilot, and pilot-to-LOI conversion.
- Restrict exports and record who accessed or changed contact data.

### Phase 2: MVP App Backend And Admin Console

```mermaid
flowchart LR
  A["Child app and parent app"] --> B["Authenticated API"]
  B --> C[("Encrypted Postgres")]
  B --> D["Incident queue and workers"]
  D --> E["Push and SMS providers"]
  E --> F["Signed delivery callbacks"]
  B --> G["Encrypted object storage"]
  B --> H["Role-based admin console"]
  H --> I["Audit logs and security review"]
```

Core production records:

- `users`, `families`, `children`, and `child_devices`.
- `safety_circle_members`, invitations, acceptance, and revocation.
- `incidents`, incident locations, notifications, actions, and resolution.
- Incident media only if approved after safety, privacy, and abuse review.
- Consent records, access logs, audit events, and deletion requests.

Production admin areas:

| Admin area | Required capability |
| --- | --- |
| Leads | View, tag, assign, export, and follow up |
| Parents | Account and verification status |
| Children | Strictly limited support view with no casual sensitive access |
| Devices | Enrollment, suspicious sessions, and revocation |
| Safety Circle | Invitation, verification, acceptance, and removal status |
| Incidents | Support review, delivery status, and resolution records |
| Compliance | Consent records, access requests, and deletion requests |
| Security | Admin activity, access logs, alerts, and incident response |
| System health | API, SMS, push, queues, database, backups, and restore status |
| Reports | Waitlist, pilot, delivery reliability, trust, and investor funnel |

### Identity And Administrative Access

Production administration must not use a shared founder credential.

| Role | Access boundary |
| --- | --- |
| Founder or authorized executive | Full approved administrative access |
| Marketing manager | Leads, campaigns, and approved public content |
| Support administrator | User support with limited incident visibility |
| Security administrator | Security logs, access review, and incident response |
| Developer | Technical tooling without unnecessary child data access |
| Investor viewer | Separate limited data room; no app-backend access |

Mandatory controls:

- Individual staff accounts and MFA.
- Role-based permissions and least-privilege access.
- Session timeout, rapid revoke, and periodic access review.
- Logged admin actions and sensitive-record access.
- No shared production administrator passwords.

### Recommended Technical Path

| Need | MVP choice | Later scale path |
| --- | --- | --- |
| Authentication | Supabase Auth, Auth0, or Clerk | Enterprise identity provider with enforced MFA |
| Database | Managed Postgres such as Supabase | AWS RDS Postgres with replicas and recovery controls |
| API | Node.js with a structured service framework | Split services only when operationally justified |
| Object storage | Supabase Storage or S3 | Encrypted S3 with lifecycle and access policies |
| SMS | Twilio or evaluated regional provider | Provider redundancy after measured need |
| Push | Firebase and APNs | Monitored multi-platform delivery pipeline |
| Email | Postmark or SendGrid | Managed transactional-email service |
| Admin | Custom role-based web console | Dedicated production control plane |
| Monitoring | Sentry and cloud logs | Central observability and security monitoring |
| Edge security | Cloudflare | WAF, rate limits, bot controls, and managed rules |

### Phase 3: Enterprise Readiness

- Queue-backed delivery workers with retries and dead-letter handling.
- Database replicas, automated backups, restore exercises, and disaster recovery.
- Central monitoring, alerting, security-event review, and incident playbooks.
- Vendor risk review and data-processing agreements.
- External penetration testing and recurring access reviews.
- Documented support, abuse, custody-dispute, and law-enforcement request workflows.

### Enterprise Backend Release Gates

- No shared production admin credential.
- MFA and role-based access controls tested.
- Audit logs capture administrative and sensitive-data access.
- Backups complete successfully and a restore test has passed.
- Production secrets are managed outside source code.
- Security, privacy, safeguarding, and legal reviews are complete.
- Incident response owners and escalation procedures are documented.

## 11. Next Decision Point

Fund **Phase 1: Closed Technical Pilot** to answer:

**Can Usalama reliably alert a verified parent and Safety Circle after a child's three-second hold, attach one emergency pin when available, capture acknowledgement, escalate when needed, support safe check-ins, and do so without continuous tracking?**