What actually keeps your data apart

Every tenant-scoped table carries a policy enforced by PostgreSQL itself (Row Level Security), not only by application code choosing what to query. A bug in a page or an API route that forgot to filter by account still can't read another account's rows — the database refuses the read at the source.

Every account-scoped table's foreign keys carry the account id alongside the record id, and every function that runs with elevated privileges pins its own search path so it can't be tricked into resolving to the wrong schema.

When you take payments, you connect your own Stripe account through Stripe Connect, using the plain "Standard" account type — the same one an independent merchant sets up directly with Stripe. We charge no application fee on what your clients pay you, and we never take custody of a card number: Stripe's own hosted Checkout and payment links handle that, which is what keeps the card-data compliance scope on Stripe rather than on us.

We hold the account identifier that says which Stripe account is yours (an acct_… id), never a secret key belonging to it. We can't move your money, and we can't see your bank account or card numbers directly.

Every authenticated screen sits behind two independent checks: an edge allow-list that blocks anonymous access by default, and a server-side session check on every request using Supabase's own session cookie verification. Privileged database access (the kind that can act across tenants, used only for a small number of specific server-side jobs) lives in one narrowly-scoped module with its call sites enumerated, not spread through the codebase.

The links your clients get for an invoice or an estimate carry a 256-bit token, not a guessable id. Those routes are checked against strict token syntax and the authorization decision is made in the database, the same isolation as everywhere else in the product.

Stripe webhook handlers verify Stripe's signature over the raw request body before acting on anything, reject requests missing a webhook secret, and record processed event ids so a retried webhook can't apply twice. Scheduled jobs (nightly reminders, billing reconciliation) authenticate with a secret compared in constant time, so a slow string comparison can't leak the secret one character at a time.

No page in this product uses dangerouslySetInnerHTML, dynamic code evaluation, shell execution, or hand-built SQL from user input. Security headers on every response include HSTS, MIME-sniffing protection, clickjacking protection, a referrer policy, and a Content Security Policy that enforces (not just reports).

This page reflects the most recent internal security review of the codebase, dated 2026-08-16. It is a source-code review, not a penetration test or a third-party audit, and it does not by itself verify the live production configuration.