Security you can verify, not just trust.
Every control on this page is enforced in our own code, not described in a policy document. We would rather show you the mechanism than ask you to take our word for it.
- Tables with RLS
- 86 / 86
- Passwords stored
- 0
- Rate limiters
- 31
- Audited actions
- 298
Not a policy document. The actual code.
Every claim below is something we could open in the source on a call, not a certificate we’re asking you to trust.
Passwordless sign-in
There is no password to phish, reuse, or leak. Every sign-in is a one-time email link, a passkey, or Google. No password sign-in path exists anywhere in the app.
Row-level security on every table
All 86 tables in the database enforce row-level security. 26 of them carry no policy at all, which Postgres reads as a hard deny — nothing outside our own service role gets in.
An append-only audit trail
298 distinct action types are written to a ledger recording who did what, to which record, and when. No authenticated session, ours included, can edit or delete an entry.
Rate limiting on every public surface
31 named limiters cover every public form and write endpoint. Sign-in and payment buckets fail closed under an outage, so a transient error can never quietly switch protection off.
Security headers on every response
A Content-Security-Policy with a per-directive host allow-list, HSTS with preload, and frame denial ship on every production response — not only on the pages that ask you for a login.
Encryption in transit and at rest
Traffic is encrypted end to end. Integration credentials are sealed at the column level with AES-256-GCM, and recovery codes are stored one-way — never in a form we could read back.
A request has to get past three gates.
Not one check repeated three times. Three different refusals, at three different moments, each one enough on its own.
At the edge
A proxy matches the protected paths, resolves your session, and checks your role before a single line of page code runs. If sign-in configuration is ever missing in production, it refuses the request outright.
At the page
Every protected area of the app carries its own guard at the root, and that guard re-derives who you are from scratch. It trusts nothing the layer in front of it forwarded, so one bad assumption upstream is not enough to open a page.
At the change
Reading a page and changing a record are separate permissions, checked separately. Every action that writes asserts its own, and a test fails our build if an action in your portal ever ships without that check.
Why three, not one
The outermost gate exists because the middle one was once shown to fail open. A page guard that redirects mid-render can arrive after the response has already started, and a visitor without JavaScript would see the page anyway. We found it, moved the check in front of the render entirely, and left a regression test on each layer so that class of failure cannot come back. We would rather tell you that than describe the result as if we had designed it that way from the start.
Where it lives,and who can reach it.
Handing over your back office means handing over your books, your payroll records and your contracts. Four answers you should have before you do that with anyone.
Each one is narrow on purpose. We would rather state exactly what we can show you than round it up into something comfortable.
Read the full privacy policy- Where it lives
One database. One region.
Your records, your documents, and your sign-in data sit in a single Postgres database and private object storage, running in AWS us-east-1. There is no second copy held at a convenience vendor, and no analytics warehouse with a pipe into your business records.
- How files move
Documents never leave through a public link.
Client files live in a private bucket the database refuses to serve directly — there is no signed URL to leak or forward. A download passes a session check, then an ownership check against your organization, and only then streams through our own origin.
- Who can reach it
Our access to your workspace is bounded and recorded.
Your team can reach your workspace, because that is the service you are buying. What we can say precisely is how: the path is signed, capped at thirty minutes, refuses every write while it is active, and writes an audit entry each time it is opened.
- How long it is kept
Retention is published, not left to discretion.
Booking records are held for twelve months after your last interaction. Engagement records are held for the length of the engagement plus seven years, because tax and accounting rules require it. Both periods are written into the privacy policy.
Everyone else in the path
Eight vendors sit in the path by default, and all eight are named here with the reason each one is there. Anything past them is a connector you authorize yourself, one at a time.
- SupabaseDatabase, sign-in, storage
- VercelHosting and edge network
- StripeBilling and payments
- ResendTransactional email
- SentryError monitoring
- AnthropicLanguage model
- TwilioBusiness phone
- GoogleSign-in, calendar, mail
Check any claim on this page.
Nothing here is meant to be taken on faith. Every figure comes from somewhere you can point at, and there are three ways to go look.
Walk the source with us
Bring your questions to a call and we will open the actual file behind any control on this page — the migration, the guard, the limiter — and read through it with you.
Ask for the written posture
We keep a security document organized by enforcement status: what is enforced in code, what exists but is not compelled, and what does not exist at all.
Send us your questionnaire
Vendor questionnaires come back answered in full, including the questions where the honest answer is no. Where one wants evidence rather than a checkbox, we attach it.
On formal certification
We do not hold a SOC 2 report or an ISO 27001 certificate today. A SOC 2 Type 1 engagement is approved and being arranged, and this page will say so when it starts and again when the report is issued. Until then, what is above is what we can genuinely put in front of you: the controls, the code behind them, and an engineer who will read it with you.
Asked before every engagement.
The ones a reviewer sends before a first call, answered here the way we would answer them on it.
See how it holds up for your business.
Pick a plan, sign up in under five minutes, and meet your team this week.