Engineering and security

Shop data is separated at the database boundary

FretTrack uses Supabase Auth, shop memberships, PostgreSQL Row Level Security, role-aware permissions, and narrowly scoped database functions. The browser interface is not the primary privacy boundary. Database policies and guarded server operations decide which shop and role may read or change a record.

• Cross-shop access is covered by database authorization checks.
• Privileged functions validate the caller, shop, role, record lifecycle, or signed token before crossing Row Level Security.
• Repair photos and shop assets use controlled Storage access rather than public buckets.
• Provider webhook requests are authenticated before billing or messaging events are accepted.

Every production change has gates

FretTrack keeps application code, database migrations, server functions, public documentation, and deployment records in source control. The checks selected for a release depend on what changed and can include:

• focused regression checks for the affected workflow;
• database migration-history, permission, RPC, tenant-isolation, and data-integrity checks;
• browser workflow checks against an isolated local environment;
• lint, dependency audit, production build, and browser-bundle secret scans;
• post-deployment checks for exact assets, routes, security headers, migrations, and live behavior.

A release is not considered verified merely because it compiled or looked correct in one browser session.

Backups are validated, copied, and exercised

The backup workflow captures database roles, schema, data, migration history, server-function source, and Storage objects. Each complete snapshot includes a file inventory, byte counts, SHA-256 checksums, table row counts, and a comparison report.

• Incomplete snapshots receive failure markers and are rejected by restore preflight.
• Secondary copies are written through temporary folders and promoted only after manifest and checksum verification.
• Local restore exercises validate database records and the actual Storage files, not metadata alone.
• Production restoration remains a deliberate, separately authorized operation.

Security work is managed as an ongoing program

FretTrack maintains a security control register, risk register, provider inventory, access-review procedure, incident-response plan, vulnerability process, backup runbook, and dated evidence records. Dependencies and automation definitions are reviewed, and third-party workflow actions are pinned to reviewed revisions.

Supabase, Cloudflare, GitHub, Stripe, Resend, and other providers operate parts of the platform, but their certifications do not automatically certify FretTrack. FretTrack remains responsible for its application authorization, configuration, releases, customer-data flows, access management, and evidence.

Data lifecycle is deliberately conservative

FretTrack keeps customer, repair, photo, message, and financial records shop-scoped and protected by the same access boundaries used during normal work. Automatic deletion is not enabled until the shop's business, legal, and customer-retention requirements are approved; this prevents an unreviewed purge from destroying repair or financial evidence.

The readiness framework defines the future deletion workflow: verify the requester and exact scope, check legal holds and disputes, export before action, remove private Storage objects with the record, and retain only the minimum audit evidence required. Backup copies expire on their documented retention schedule rather than being rewritten.