Your practice's information stays yours
Plain answers to the question every practice asks first: how do we know our information is kept safe and never shared? Everything here describes how the app works today.
Your practice's data is kept apart from everyone else's
Each practice has its own workspace. The database itself enforces this with row-level security: every read and write runs as your signed-in account, and rows that belong to another practice are refused, even if the application code had a mistake in it. We test this automatically on every change.
How we know: Postgres row-level security on every workspace table, with automated isolation tests.
You decide who sees what
Owners and admins invite people and choose their role: owner, admin, member or viewer. Removing someone stops their access straight away. Invite links work once, for 14 days, and only for the email address they were sent to.
How we know: Role checks in the database policies and on every server action.
Every change is recorded, including ours
Your audit log records who changed what and when: settings, branding, team changes and modules. Nobody can edit or delete an entry. If anyone at Orderhatch ever opens your workspace, for example to help you set up, that visit is logged and shown to you.
How we know: Append-only audit log; Orderhatch staff access always writes an entry first.
Encrypted on the way and at rest
The app is only served over HTTPS; plain HTTP requests are redirected. Your data is stored with our database provider, Supabase, which encrypts all customer data at rest with AES-256.
How we know: Vercel: every deployment served over HTTPS, HTTP redirected (TLS 1.2 and 1.3). Supabase security page: customer data encrypted at rest with AES-256.
Enquiries belong to your practice
If you use the enquiry form, what people send is your practice's data, kept apart and protected like everything else here. We keep only the answers the form asks for and when they were sent: no IP addresses or browser details. Spam protection uses a short-lived one-way hash instead. The site check sends only the postcode to postcodes.io and a map point to planning.data.gov.uk and the Environment Agency, all free public services, never anyone's name or contact details. If your practice has exact address checks (an add-on, off unless Orderhatch switches it on), the postcode is also sent to Ordnance Survey once to list its addresses, so the person can pick theirs and the site is checked at the property itself; the chosen address and its map point are kept on the enquiry, and lookups are counted against your practice's add-on. The small map on an enquiry is loaded from OpenStreetMap, which sees the map area being viewed. Confirmation emails are only sent if you switch them on.
How we know: 0042_practice_enquiries.sql (columns stored); rate_limit_hits holds salted hashes only; src/lib/server/constraints.ts sends only the postcode and coordinates; src/lib/server/address-provider.ts sends only the postcode to OS Places (0050_practice_constraints_v2.sql: add-on off by default, usage counted per month); confirmation email off by default.
Planning records stay in your workspace
Planning applications, conditions and checklists are your practice's data, protected by the same rules as everything else here: viewers can look but not change, and every change is in your audit log. We never log in to or copy from council planning portals; a link to the council's page is only something you paste in. Evidence for conditions is a name and a link, or a document from your Drawings & documents library. Deadlines are worked out in the app from published national rules, and each one shows where its rule comes from.
How we know: 0043_practice_planning.sql (row-level security, module gating, no grants to anon or the public form role); src/lib/core/practice-planning-dates.ts (rules with source URLs); src/lib/server/practice-planning.ts makes no outbound requests.
Drawings and files are private to your practice
Files you upload to Drawings & documents are stored in a private store, inside a folder that belongs to your workspace. There are no public links: each time someone opens or downloads a file, we first check they're a member of your workspace, then hand them a link that stops working after five minutes. Viewers can open and download but can't change anything. Uploads are checked on our server: only PDF, DWG, DXF, IFC, PNG, JPG, DOCX and XLSX files up to 100 MB, and the start of each file must match its type. Uploads, new revisions, issues and downloads are in your audit log. Orderhatch never emails a transmittal for you: you send it from your own email.
How we know: 0044_practice_drawings.sql (row-level security; object keys must start with the workspace id; private bucket with no storage policies); src/lib/server/practice-files.ts (signed URLs, 300-second expiry); src/lib/core/practice-files.ts (types, size cap, content check); src/app/practice/files/[ws]/[id]/route.ts (membership check before every file).
Fees and invoices: locked once issued, and never sent by us
Fee proposals, invoices, payments and time are your practice's data, kept apart like everything else here. Only owners and admins can issue, void or credit an invoice, record payments, change bank details or set cost rates; viewers never see bank details or anyone's cost rate, and members see how much of a fee has been used as a percentage, not the rates behind it. Invoice numbers come from one sequence the database won't let repeat, and once an invoice is issued the database refuses any change to it: corrections are made with a credit note. Every change to money is in your audit log, though bank details and cost rates themselves are never written there. Orderhatch never emails an invoice or a reminder: you print it or open it in your own email. There's no connection to any bank or accounting software; exports are files you download.
How we know: 0045_practice_fees.sql (row-level security; practice_can_bill for issuing, payments and settings; cost rates readable by owners and admins only; bank details hidden from viewers; unique index on invoice numbers; practice_invoice_lock and practice_invoice_line_lock triggers); src/lib/server/practice-invoices.ts makes no outbound requests.
Building Safety records: evidence you keep, never a verdict
Duty-holder appointments, competence evidence, classifications, gateway and building control steps, key documents and design risks are your practice's data, kept apart like everything else here. Viewers can look but not change anything; duty-holder appointments can only be recorded by owners, admins or the project's lead, and your practice's own details only by owners and admins. Every change is in your audit log. A linked drawing or document must belong to the same project in your workspace. Orderhatch never submits anything to the Building Safety Regulator, HSE or a council for you, and makes no outbound requests for this module. Dates are worked out only from published statutory periods, each with a link to the regulation. It's a record-keeping aid, not legal advice, and it never says anyone is compliant.
How we know: 0046_practice_safety.sql (row-level security, module gating, practice_can_appoint, practice_safety_org_ok, no grants to anon or the public form role); src/lib/server/practice-safety.ts checkDocLink; src/lib/core/practice-safety-rules.ts (rules with source URLs); src/lib/server/practice-safety*.ts make no outbound requests.
Client portal: your clients see only what you share
Clients sign in to their own area. They aren't members of your workspace and can't open it. Each client sees one project, and only what you share with them item by item: a particular drawing revision or document version, the planning application's status in plain English, issued invoices with your bank details for paying by transfer, the updates you post, the message thread, and the contact person you choose. Until you share something, they see nothing of it. They never see your internal notes, revision notes, the team list or anyone's details beyond the names you choose to show, your activity or audit log, timesheets, cost rates, fee proposals, enquiries, the Building Safety record, settings, other projects or other clients. The database enforces this with a separate role for clients that is only allowed to read those shared items and only the parts of them meant for clients. Clients can approve or ask for changes, reply, say they've paid by bank transfer (a note you confirm; no money moves through Orderhatch) and update their own name and phone, and every one of those actions is in your audit log under their name. Invite links work once, for 14 days, and only for the email address invited; removing someone ends their access immediately. Orderhatch doesn't email your clients: you send the invite link yourself, and their messages wait in your inbox.
How we know: 0047_practice_portal.sql (practice_client role: column-level grants, its own row-level policies, practice_client_sees and the practice_portal_* functions that audit as 'client'; sha256 invite token hashes with expiry); tests/practice-portal-db.test.ts (raw SQL as a client against every internal table, cross-project and cross-practice isolation, revoked access, token lifecycle).
Reports: worked out from your records, never sent anywhere
Reports are worked out each time someone opens the page, from the records that person can already see, through the same access rules as the rest of the app. No copy of the figures is kept and nothing is sent to anyone. Viewers see no money figures at all, and the cost of hours in pounds is only shown to owners and admins; members see fee used as a percentage. Example data follows the workspace's one "Show example data" switch, the same on every screen. The partners' pack is printed or saved as a PDF from your own browser, and CSV downloads are files you save: Orderhatch never emails them. The only thing stored is when your financial year starts, which only owners and admins can change, and each change is in your audit log.
How we know: 0052_practice_reports.sql (only the financial-year setting: row-level security, owners and admins write, billing read-only guard); src/app/practice/[workspace]/reports/data.ts (the modules' own loaders; money left out for viewers, cost of hours only for owners and admins); src/lib/core/practice-reports*.ts (pure functions, tested in tests/practice-reports*.test.ts, including a reconciliation with the Fees Money overview).
Knowledge base: drafts stay with the team, pages are cleaned before they're stored
Owners, admins and members write pages; viewers only ever see published pages, never drafts, deleted pages or a page's history. The database enforces this, not just the screens. Every save keeps a version with who saved it and when, so an older version can be read, compared and put back, and deleting a page (owners and admins only) can be undone. Page text is cleaned on our server before it's stored: scripts, embedded frames, event handlers, styles and links that aren't web, email or in-app addresses are removed. Files attached to a page use the same private storage and checks as Drawings & documents. Hatch reads pages as the person asking, so a viewer's Hatch can't see drafts either, and it treats page text as information, never as instructions. Creating, editing, publishing, restoring and deleting are all in your audit log.
How we know: 0053_practice_knowledge.sql (row-level security: viewers read published, undeleted pages only; versions for owners, admins and members; deleting needs owner or admin; billing read-only guard); src/lib/core/practice-knowledge-sanitize.ts (allow-list cleaner, tested in tests/practice-knowledge.test.ts against script-injection cases); src/lib/server/practice-hatch-tools-kb.ts (read-only, as the signed-in person, page text wrapped as untrusted data).
Never sold, never shared
We don't sell your data or share it with anyone. The only companies that handle it are the ones that run the service, such as our database and hosting providers, under contract. They're listed in our Data Processing Agreement.
How we know: Orderhatch privacy policy and DPA sub-processor list.
AI helpers: off unless you switch them on, and drafts only
AI helpers are off until Orderhatch makes them available to your practice and an owner or admin switches them on after reading a notice, and each helper can be turned off on its own. When someone asks for a draft, only the information listed under "What the AI will see" is sent, to Anthropic's Claude API, which acts as our sub-processor for this feature. Email addresses and phone numbers are taken out first. We never send cost rates, bank details or other clients' information, and a client update only uses what that client can already see in their portal. Anthropic's commercial terms say they may not train models on this content, and their published policy is to delete API inputs and outputs within 30 days, unless they're flagged for a usage policy breach (kept for up to 2 years) or the law requires otherwise. Every result is labelled as an AI draft for a person to check: nothing is emailed, posted to the portal or saved to a record unless someone clicks to do it. It isn't legal, planning or regulatory advice, and the AI is instructed never to say anything is compliant. Text from documents and enquiries is marked as information for the AI, not instructions, and the helpers can't take any action themselves: they only return text. We record who used which helper, on which record and how much, but not what was written, apart from your own "This week" summary, which is kept for that day. Usage is capped for each practice and each person.
How we know: 0048_practice_ai.sql (off by default; practice_ai_can_use; caps enforced by a trigger; usage rows hold counts, never text); src/lib/core/practice-ai-prompt.ts (redaction, untrusted-data wrapping, no tools); src/lib/core/practice-ai-build*.ts (each helper's allow-listed fields); tests/practice-ai*.test.ts. Anthropic Commercial Terms section B, https://www.anthropic.com/legal/commercial-terms; retention, https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data; training, https://privacy.claude.com/en/articles/7996868-is-my-data-used-for-model-training (checked 22 October 2026).
Hatch: a read-only assistant that sees only what you can see
Hatch, the assistant panel, is part of the AI helpers: it's off until AI is switched on, and an owner or admin can turn it off on its own. It only reads. To answer a question it looks things up as the person asking, through the same access rules as the rest of the app, so a viewer can't see cost rates or bank details through it and it can never see another practice's workspace. It has no way to send, create, change or delete anything; if you ask it to, it points you to the page where you can do it yourself. The question and what its lookups return are sent to Anthropic's Claude API on the same terms as the helpers, with email addresses and phone numbers taken out and text from enquiries marked as information, not instructions. Links in its answers are checked against the records it looked up, and anything else is removed. Conversations are kept for the period your owners and admins choose (off, 7, 30 or 90 days; 30 unless changed), are visible only to the person who had them, and can be cleared at any time. Every answer says it can be wrong and isn't professional advice. Spend on Hatch and the helpers is counted in pounds against a monthly budget set by Orderhatch, with optional limits per person.
How we know: 0049_practice_hatch.sql (Hatch in practice_ai_can_use, including viewers; conversations readable only by their owner; retention and purge; budget in the caps trigger); src/lib/server/practice-hatch-tools*.ts (read-only tools, allow-listed fields); src/lib/core/practice-hatch.ts (link checking); tests/practice-hatch*.test.ts.
Paying Orderhatch: handled by Stripe
Your Orderhatch subscription is billed by Stripe. Card and Direct Debit details are entered on Stripe's own secure pages, so we never see or store your full card number or bank details. Stripe emails your receipts. If a payment fails, nothing is deleted: you keep full access for a grace period, then the workspace becomes read-only until it's sorted, and you can export everything at any time.
How we know: Stripe Checkout (setup mode) and the Stripe Customer Portal for payment details; only Stripe customer and subscription ids are stored. Read-only enforced by the 0051 database trigger; no delete path.
Yours to take, or to delete
Owners and admins can download a copy of the workspace's records (a ZIP of spreadsheet files) from Settings → Billing at any time, whatever the state of the subscription. Ask and we'll delete it: email hello@orderhatch.co.uk from an owner's address.
How we know: Settings → Billing → Export your data (CSV files of core records, read through row-level security). Deletion handled by Orderhatch on request.
A Data Processing Agreement
Our Data Processing Agreement sets out how we handle your data, who our sub-processors are, and where your data is hosted. Ask us for a copy for your practice. Hosting region: confirmed in your DPA.
How we know: orderhatch.co.uk/dpa
Questions about security? Email hello@orderhatch.co.uk and you'll get a straight answer from the person who built it.