Last updated 5 September 2026
Trust and security
Purchase orders, price lists and margin are among the most sensitive things a brand has. This page says how they are protected, where they are held, who else touches them and what we do not yet have — stated from what can be verified in our source code and on our platform, so that a reviewer can check it rather than take it on trust.
Where data is held
Workspace data is stored in Postgres 17 on Supabase, in AWS eu-west-2 (London, United Kingdom). It rests in the United Kingdom. The application itself is served by Vercel.
Controls, in one paragraph each
Isolated per workspace. Every record carries a workspace id and row-level security is enabled on every application table, so one customer's data is not reachable from another's session. A database event trigger enables RLS on any new table automatically.
Encrypted in transit; encrypted at rest by the provider. All traffic is served over TLS with HSTS. Our managed Postgres provider encrypts data at rest; that is a property of the platform, and we state it as such.
Integration credentials encrypted. API keys and OAuth tokens for connected platforms are encrypted with AES-256-GCM using a key held only on the server, and are never returned to the browser.
Verified webhooks. Inbound webhooks are verified by signature or shared secret before anything is written. A request that fails verification is rejected and the rejection is recorded.
Least privilege by role. Owner, admin, operator and viewer roles gate every action on the server, and the same rule is enforced again by database policy — a role that lacks a permission cannot write the row even if the interface were bypassed.
Audited. Changes to orders, connections, pricing, team access and security settings are written to an audit log with the acting user and time. No user of the application can edit or delete an entry.
No third-party scripts. The application loads no analytics, tag manager, session recording or advertising script, and the Content Security Policy permits scripts only from our own origin with a per-request nonce.
An AI off-switch that actually switches. A workspace can turn the AI features off. The setting is enforced at the single point every model call passes through, before any content leaves — not in the screen that sets it.
Authentication
Two-factor authentication with an authenticator app is available to every login and is turned on by the person themselves, in Settings. Single sign-on: No. A workspace requiring two-factor of all its members: No — not yet; it is next on the authentication roadmap.
Who else processes your data
Supabase, Vercel, Resend, Google (Gemini API). What each one receives, and why, is on the sub-processor page.
Backups and continuity
Schema in version control and rebuilt from empty in CI on every change: Yes. Provider-managed daily database backups: Yes. Point-in-time recovery: No. A restore rehearsed and timed: No. A guaranteed uptime level: No. What each answer means →
Independent assurance
SOC 2: No. ISO 27001: No. Cyber Essentials: No. Independent penetration test: No.
We are an early company and none of those exists yet. What exists instead is that every control on this page is verifiable in our source and our database, and we will walk a reviewer through the evidence on request — the row-level security policies, the credential encryption, the audit log’s grants, the Content Security Policy — rather than ask them to accept a badge.