For enterprise operators
The operating layer
behind your workspace.
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.
The questions that matter at scale
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.
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.
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.
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.
What we actually built
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.
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
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
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
- 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
Enterprise terms
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.
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 and we’ll be straight with you.