Application data reads and writes stay behind the NestJS backend, which uses the Supabase service-role key. Launch-facing risk is controlled through backend ownership checks rather than browser-side direct table access.
Clinic-owned records are treated as clinic-scoped data. The documented architecture keeps cross-clinic access behind explicit clinic ownership checks, with a separate RLS rollout plan for any future direct browser access.
The platform records audit writes, rate-limit and webhook security events, and runs route-level throttling on public and auth-sensitive paths.
Clinic signup, dashboard registration, public booking, and portal registration all capture explicit privacy acceptance. Soft-deleted operational rows, privacy requests, security events, and webhook receipts follow retention schedules.
Daily automated database backups, restore drills, rollback planning, and prelaunch verification are documented as operational requirements before launch.
The compliance notes call out encryption in transit, scoped secrets, least-privilege service access, and documented vendor review before new processors are added.
Browser requests go through the Next.js app and then the NestJS backend before application data reaches Supabase. That keeps application data access on the backend side while the team hardens any future RLS rollout table by table.