Every product in this category assumes a human is present
Connecting a custom domain is the most common drop-off point in SaaS onboarding. There is a mature category of products that solve it, and they solve it well: an embedded modal walks the user through logging into their registrar, and the records get written for them.
That flow has a person in it by design. Someone reads the consent screen, types a password, and clicks approve. The system this was built for does not have that person available at that moment. An agent provisioning a mailbox on a user's own domain needs the DNS write to be a callable operation with an honest return value, not a modal waiting for a click.
The price follows from that, and is worth stating because it is public rather than because it was the motive. The incumbent category's entry tier lists at $249/mo for record-writing, and $749/mo for the tier that also serves the custom domain. The commodity layer underneath all of it — Cloudflare for SaaS custom hostnames — is $0.1/hostname/mo with the first 100 free. The gap between those two numbers is the convenience layer. Paying for convenience is a good trade right up until the convenience is a modal you cannot click.
4 days
build window, 15 commits
270
test cases over the engine
6
HTTP endpoints
4
DNS provider adapters
What was deliberately not built
This is the part that decides whether building instead of licensing was judgment or self-indulgence, so it goes before the architecture rather than after it.
No ACME client was written. Certificate issuance and renewal are Cloudflare's, and that was never in scope. No registrar API was reimplemented; where a provider has one, Latch calls it. No attempt was made to match the incumbent's breadth of registrar integrations — they advertise sixty-plus, this has 4, and the honest fallback for everything else is a guided manual flow that tells the user exactly which records to paste. Breadth of registrar coverage is a maintenance tax, not an algorithmic asset, and it is the wrong thing for one person to try to own.
What had to be ours is narrower: the orchestration across detect, connect, and verify, and the email-DNS correctness rules below. That is where the unattended path lives, and it is the only part where the incumbent's design actively conflicts with the requirement.
The condition under which this was the wrong call is easy to state: if a product in this category ships an unattended, agent-authorizable connect flow, buying wins and this gets replaced. That has not happened yet. It is the thing to watch, not a hypothetical.
Three verbs, and the honest return value
detect
Find where a domain’s DNS actually lives, by matching authoritative nameserver suffixes and probing for a Domain Connect endpoint. Live NS lookup first, SOA MNAME second, WHOIS last. Reports DNSSEC, parked, and unregistered states up front, because each one changes what is possible next.
connect
Write the records where we hold credentials, hand back a guided manual flow where we do not. Every call resolves to one of three honest outcomes: applied, manual fallback, or OAuth required. There is no fourth state that means "probably worked".
verify
Confirm from the outside, against multiple DNS-over-HTTPS resolvers, rather than trusting the write we just made. Polls at ten seconds, backs off, and keeps the job alive for 72 hours because propagation genuinely takes that long at the tail.
The engine is zero-dependency TypeScript with no runtime globals in it, so the same code is exercised by 270 test cases without a network and runs unchanged on Workers. Providers are a registry: Cloudflare is live, Domain Connect is built but switched off, Route 53 is implemented against known-answer tests for its SigV4 signing but has never been run against a live account, and Namecheap is authored but unwired because its API is IP-allowlisted and eligibility-gated on the end user. Those four states are tracked separately on purpose, because "we wrote an adapter" and "this provider works" are different claims.
The hard part is email DNS, not DNS
Writing an A record is trivial. Writing mail records into a domain that already sends mail is where automated DNS tools quietly break production email for someone who did nothing wrong. Each rule below exists because the naive version of it is a real outage.
- SPF is merged, never appended. A domain may hold exactly one SPF record. Adding a second is the single most common automated-DNS failure and it fails closed on every message. Latch parses the existing record, merges the new include, and preserves the original all qualifier rather than helpfully upgrading ~all to -all.
- The 10-lookup ceiling is a refusal, not a flatten. SPF permits ten DNS lookups per evaluation. At the ceiling, the tempting move is to flatten includes into literal IPs, which works today and silently rots the moment the provider changes address. Latch refuses and says why.
- DKIM record type is provider-specified. Some providers want a CNAME at the selector, some want the public key inline as TXT. A TXT value over 255 octets is chunked inside one record rather than split across several, because those are not the same thing to a resolver.
- Any existing MX is a hard stop. If a domain already receives mail somewhere, quietly repointing MX takes down their inbox with no error anywhere. The job halts and surfaces an explicit warning instead. This is the failure mode most worth being slow about.
- Apex CNAME is refused outright. RFC 1034 does not allow it to coexist with the SOA and NS records every zone apex must carry. Providers that appear to support it are doing flattening behind the scenes; Latch does not pretend the record type exists.
Four days, and the two times it was wrong
Engine frame and the canonical contract
Contract first, in a portable zero-dependency TypeScript core with no Cloudflare or Node globals in it. The engine had to be testable without a network and portable off Workers later.
Records, detect, providers, verify
The first working slice, plus a red-team pass over the connect orchestrator before any of it was reachable from outside.
The reversal: verify was overstating itselfcorrection
Originally verify reported "published" whenever the records read back correctly. That was wrong for zones we do not control, where reading a record from one resolver does not mean the world sees it. The status was demoted so external zones cap at "confirmed" and only authoritative zones reach "published". Weaker claim, true claim.
Worker, SDK, and the agent tools
HTTP surface at latch.gbuild.app, a typed SDK, then MCP tools plus a declarative manifest adapter so new providers are described as data rather than shipped as generated code.
Marketing and docs site, self-contained
Served from the same Worker as static assets. The pricing page states plainly that the paid tiers are roadmap rather than self-serve, because the service is still single-tenant.
The auth gap, recorded before it was fixedcorrection
Runtime verification on a real device found the shipped sidecar had no way to obtain a signing secret. That was written down as a known gap first, then closed by routing through the API gateway so no signing secret sits on the device at all.
Both marked entries are the same shape: a claim the system was making turned out to be stronger than the evidence behind it, and the claim got demoted rather than the evidence talked up. A verify status that says "confirmed" when it cannot prove "published" is worth more than one that is right most of the time.
Where it actually stands
The service is deployed and answering at latch.gbuild.app. The engine, the HTTP surface, the SDK, the manual fallback, and server-side verification are all real and running.
What is not finished: the desktop client that consumes it still points at the service directly, so the bring-your-own-domain flow is not functional in the field until the next sidecar release carries the gateway transport. Multi-tenant use needs per-tenant secrets before a second caller exists — today there is one global application secret and exactly one caller, which is fine right now and would not be fine with a customer on it.
One capability is withheld deliberately rather than unfinished. The agent-facing tools expose detect and verify but not connect. A DNS write is an outward, hard-to-reverse change to something a user owns, and it stays on the human plane until the consent model around outward writes is finished. The service can do it; the agent is not allowed to ask.