Custom domains as a service
The category of SaaS that abstracts custom-domain infrastructure (TLS, routing, DNS monitoring) behind an API so other SaaS don't have to build it.
Custom Domains as a Service (sometimes CDaaS) is the category of B2B infrastructure products that let other SaaS offer their customers branded URLs without building the underlying TLS + routing + monitoring stack themselves.
Why the category exists
Every multi-tenant SaaS eventually faces the same engineering project: let our customers point their own domain at our app. Building it well takes 4–8 weeks for v1 and never stops needing care: cert renewal, DNS health checks, rate limit management, ACME protocol updates. The work isn't novel; it's the same problem solved at every SaaS that grows past pilot.
The economics flip toward "buy" around 50–100 active custom domains, when the maintenance load eats more than 5 engineering hours a week.
What's in scope
The thing being sold is roughly:
- A REST API to register customer hostnames.
- An edge that terminates TLS for each hostname.
- Automatic cert issuance and renewal.
- DNS monitoring with status events.
- Webhook events for state changes.
- Per-hostname routing to your origin.
What's typically not in scope:
- The customer's DNS hosting (lives at their registrar).
- Domain registration (different product: see Domain API).
- CDN-style content caching (some providers include light caching; most don't).
Build vs buy framing
Build if: you have very specific routing or compliance requirements that no off-the-shelf provider meets, OR you're already at ~10,000+ custom domains where the per-domain pricing of a service starts hurting more than the build cost.
Buy if: you have fewer than ~5,000 customer domains, you don't have a dedicated infrastructure team for this surface, and you'd rather ship product features than wait on Let's Encrypt rate limits.
Most SaaS teams in the 50–5000 custom-domain range get a clear ROI from buying.