# The operating layer behind your workspace. Postgres RLS isolation - Full settings audit log - Stripe Connect — your account - Built in New Zealand At scale, the questions stop being about features and start being about architecture: who can read which tenant’s rows, who changed which setting, and whose bank account the money actually lands in. LiteHQ has straight answers to all three — and we’ll be honest with you about everything we don’t have yet. ## Three architecture problems most workspace tools paper over. These aren’t feature gaps — they’re structural decisions a vendor makes on day one and can rarely retrofit. We made them deliberately. - **Isolation risk** ### Tenant isolation that only lives in app code. Most workspace tools separate tenants with an if-statement in the application layer. One missed check in one endpoint and another operator's member list is readable. At enterprise scale that's not a bug class you can accept. - **No audit trail** ### Config changes nobody can reconstruct. Billing rules, booking policies, branding, payment settings — changed by whom, when, from what value? When the answer is 'check Slack', every incident review and every audit becomes archaeology. - **Money-path risk** ### A vendor sitting in your money path. Some platforms pool member payments through their own account and remit to you later. That's float risk, reconciliation pain, and a vendor dependency your finance team has to underwrite. ## Architecture you can verify, not promises you have to trust. Ask us how any of this works and we’ll walk you through it — including the regression tests that guard it. - **Solves isolation risk** ### Postgres row-level-security tenant isolation Tenant separation is enforced in the database, not just the application. Every tenant-scoped table carries row-level-security policies, so a missed check in app code fails closed instead of leaking another operator's data. - RLS policies on tenant data, enforced by Postgres itself - Isolation invariants covered by SQL regression tests - Scoped magic links — no shared front-desk passwords - **Solves the audit gap** ### Full settings audit log Every change to organization settings is recorded — which field, the old and new value, who changed it, and when. Billing rules, booking policies, branding, payment config: one row per changed field, queryable by your admins. - One audit row per changed field, automatically - Covers billing, booking, branding, and security config - Read access scoped by the same RLS model - **Solves money-path risk** ### Stripe Connect platform model Member and tenant payments settle into your own Stripe account — LiteHQ never holds your money. Invoices sync to Xero on the same record, so what your front desk charges is what your accountant reconciles. - Payments land in your Stripe account, not ours - Xero invoicing + reconciliation on the same record - No platform fee on payments ## What’s true today - Postgres row-level security on tenant data - Settings audit log on every config change - Stripe Connect — funds settle to your account - Data hosted on Supabase in AWS Sydney (ap-southeast-2) - Sentry monitoring across client, server, and edge - Month-to-month terms — no lock-in ## We’re early. We’ll tell you exactly what that means. No SOC 2 certification yet. No contractual SLA percentages we can’t stand behind. What you get instead: a small team in New Zealand that built every layer of the system, answers security questions directly, and will scope your requirements honestly — including telling you if LiteHQ isn’t the right fit yet. Bring us your requirements. Security review, procurement questions, custom terms — email us and we’ll work through them with you, with the people who actually built the platform on the call. ## Run your workspace on verifiable architecture. Postgres-enforced tenant isolation, a full audit trail, and payments that settle in your own account. Talk to us about enterprise terms — we’ll be straight with you.