Run it on your own domain

Point a hostname you own at your account so every link your customers receive comes from your domain instead of the software's.

What it is

A tenant admin adds a hostname in Settings, gets back the exact DNS records to paste at their registrar, and once verification passes the platform issues a certificate and starts routing that hostname to their account. From then on every customer-facing URL the account generates — estimate links, invoices, contracts, portal links, invites — is built on that domain.

Also called: custom domain · white label · app.mycompany.com · our own branded link · CNAME

See it
Run it on your own domain
Area
Platform & Admin
Group
White-label
System
Multi-Tenancy & Identity
Solves
3 named problems
01Settings → Custom Domain posts the hostname to /api/organizations/custom-domain (admin-only).
02The server checks it isn't already claimed by another tenant, then attaches it via the hosting provider's domains API and stores the returned DNS records.
03The UI shows three states — empty, pending (records to copy plus a re-check button), verified — and re-checks against the provider on every load.
The Custom Domain tab in its pending state: hostname entered, a table of DNS records with copy buttons, an amber 'pending' status dot, and a Re-check button. Rendered by src/components/settings/CustomDomainTab.tsx. Sample data — no customer information appears here.
How it works
  1. 1Settings → Custom Domain posts the hostname to /api/organizations/custom-domain (admin-only).
  2. 2The server checks it isn't already claimed by another tenant, then attaches it via the hosting provider's domains API and stores the returned DNS records.
  3. 3The UI shows three states — empty, pending (records to copy plus a re-check button), verified — and re-checks against the provider on every load.
  4. 4Only status 'verified' is honoured for routing: a pending or misconfigured domain falls back to the platform default so a half-finished DNS change never locks anyone out.
  5. 5getOrgSiteUrl() puts the verified domain first in the link-building order, and the cache is invalidated the moment the domain changes.
Why we built it

Customer-facing links are the most public thing the software produces, and a builder sending a quote wants it to look like it came from their company. The routing rule is deliberately conservative: the middleware note says pending and error domains 'still return the platform default so a misconfigured DNS doesn't lock anyone out', and orgSiteUrl repeats it — only verified domains are honoured 'so a misconfigured tenant doesn't ship broken links to their customers.' The token that talks to the hosting provider is never exposed: 'The platform owner sets it once at deploy time; tenants never see or interact with the underlying token.'

The problem
  • Customer trust drops when a quote or invoice link points at a domain they have never heard of.
  • DNS setup is the step most non-technical owners get wrong, so the exact records have to be shown and re-checked.
  • A misconfigured domain must degrade to a working default rather than break every outgoing link.
Sound familiar?
What you get
Estimates, invoices, contracts and portal links all arrive on your domain.
You can see exactly which DNS records are missing and re-check without waiting.
A domain that isn't verified yet silently keeps using the working default, so nothing breaks mid-setup.
What's inside

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →