SecureVisit

A demo-ready MVP of a correctional communications platform: families and residents (incarcerated people) exchange reviewed messages and scheduled video visits, and facility staff approve, monitor and audit everything.

The buyer is the facility, not the family, so the product is built around staff control: connection approvals, message review, keyword flagging, live visit monitoring, and an append-only audit log.

Demo software. All people, booking numbers and facilities in the seed data are fictional. Not for production use without the items under What production would need.

The product name is a placeholder; rename it with one value: NEXT_PUBLIC_APP_NAME.

What's in the MVP

Area	What works
Accounts	Family sign-up with ID photo upload (stored, not verified); resident kiosk login (booking number + PIN, lockout after 5 failures, forced PIN change on first login); staff and admin accounts
Connections	Family requests a resident by name + booking number; staff approve/deny; residents only ever see approved contacts
Messaging	Text + family photo attachments; every message is held for review or auto-delivered and logged (facility setting); keyword hits are always held; approve / reject (with reason) / flag; per-message fee hook (always 0)
Video visits	Staff publish slots; families request; staff approve; weekly-limit and capacity enforcement; browser video via Daily; staff can watch silently and end any live visit; metadata only
Staff console	Dashboard, residents (intake, PIN reset, block contact, suspend), settings, keywords, staff accounts (admin), filterable/exportable audit log

Payments: prepaid family balance with per-facility message and visit prices, Stripe Checkout deposits on the web, refunds for undelivered messages and visits that don't happen. See docs/PAYMENTS.md.

Out of scope (not built): phone calls, commissary/trust deposits, media store, real ID verification, multi-facility billing, jail-management-system integration.

Architecture

flowchart LR
  subgraph Next["Next.js app (Vercel)"]
    F["/family (PWA)"]
    R["/resident (kiosk)"]
    S["/staff (console)"]
    API["Route handlers + server actions<br/>zod-validated"]
  end
  subgraph Supabase
    AUTH[Auth]
    DB[(Postgres + RLS)]
    ST[(Storage: ID photos, attachments)]
  end
  VID["Daily (hosted WebRTC)"]
  F & R & S -->|user JWT| DB
  F & R & S --> AUTH
  F & R & S --> ST
  API -->|service role, server only| DB
  API -->|create room / token / delete room| VID
  F & R & S -.->|join with short-lived token| VID

Security model, in short:

• Row Level Security on every table. The browser talks to Postgres with the user's JWT. Families see only their own rows, residents only approved contacts, staff only their facility.
• Writes go through security definer functions (send_message, request_connection, decide_visit, …) that re-check role, facility, contact status and suspension. Clients have no direct INSERT/UPDATE/DELETE on any business table.
• Message routing happens in the database, not the client, so a client cannot choose to skip review.
• Audit log is append-only: written only by trusted functions, with update/delete/truncate blocked by triggers.
• facility_id is on every record (multi-tenant ready).
• Role and facility live in app_metadata, which clients cannot edit; public Auth sign-up is disabled and accounts are created by server routes only.
• No secrets in client code; the service-role key is only imported by server-only modules.

Mobile apps (iOS and Android)

mobile/ is an Expo app for family and friends. It runs on the same backend as the website: one Supabase project, the same accounts, RLS policies and database functions, and the same Next.js API routes (it sends a Bearer access token instead of a cookie). Messages, visits and connection requests sync in both directions. The staff console and resident kiosk stay web-only.

• Realtime: the website (family and staff pages) and the app subscribe to Supabase Realtime, and polling remains as a fallback.
• Push notifications: database triggers write to push_outbox with fixed, content-free text. The push-dispatch edge function delivers them through Expo Push.
• Setup, environments and store release: docs/mobile/RELEASE.md. Proof-of-concept status: docs/mobile/POC-RESULTS.md. Payments policy notes: docs/mobile/PAYMENTS-POLICY.md.

Local setup

Requirements: Node 20+, Docker (for local Supabase).

npm install
npx supabase start            # first run pulls images (a few minutes)
cp .env.example .env.local    # then fill in the keys printed by `npx supabase status -o env`
npm run db:reset              # applies migrations + seeds demo data
npm run dev                   # http://localhost:3000

.env.local values for local development:

This is the beginning of the README. Read the rest at the original. Read the full README ↗