2026 — Design & Full-Stack Build (solo)

Proof you can watch

// MOST VERIFICATION SAYS "CHECK BACK IN 48 HOURS". THIS ONE ASKS YOUR NAMESERVERS AND SHOWS EVERY STEP AS IT LANDS.

DomainClaim lets you claim a domain and prove you control it with one DNS TXT record. Most products stop at "add this record and check back in 48 hours". This one asks the domain’s own nameservers and shows the check as five steps as they land: find the zone, reach the nameservers, find the record, match the value, record the claim.

Every failure has a name, a reason and one next action. Ownership keeps being checked after it is proved: a name whose record stops answering moves to At risk, and back when the record returns.

What goes wrong

I started with the ways verification fails, before any screen. A resolver that looked too early caches "no record" for up to an hour. DNS panels add your domain to the name you type, so the record lands at the wrong name. A value gets pasted with an end missing. The record is saved as the wrong type. A wildcard answers with another service’s record. One nameserver is down. The token runs out.

Each of these needed its own answer, and each one shaped the product.

Built twice

I built the engine first: the DNS walk, the typed failures, one owner per name, and a demo namespace where every failure is reachable. The screens got the time that was left, and the stack shaped them into three separate pages.

The first people outside to use it found the problems in the frame. The sign-in link needed a second click, and the layout shifted between screens. Both were on my list, and I had deferred both. So I kept the engine and started the design again from a blank page, in HTML prototypes.

I drew three directions from how DNS fails and where the person acts or waits: a rail with a drawer, a scrolling timeline, and the claim as a patch network. The timeline won. It carried the check as one horizontal row of steps on a single cable.

The next version applied a whole list of changes at once and lost what made the timeline work. From then on each prototype changed one thing, and I decided each change before it was made. The design converged in a day.

Only real states

Before choosing a stack I checked every state in the design against the backend’s real types. Anything the app couldn’t reach was cut or marked as future work. "Just registered" and "no nameservers set" look the same in DNS, so they became one state. A promise in the copy became build work, or the copy changed.

The stack came last, with one rule: pages never load data, and screens fetch from the API. The check streams its real steps. It never animates a sequence over one finished answer.

The code is built to be read. DNS sits behind an interface with a scripted fake, so no test touches the network. Failures are values in a typed union, and the message switch is exhaustive: a new failure breaks the build until it has words. An RFC leads the code, and a friction log records every problem I hit using it against real domains. The unit tests cover the pure layers, and the README names what they don’t.

export type FailureReason =
  | { code: 'record_not_found'; queriedName: string;
      nameservers: string[]; negativeTtlSeconds: number | null }
  | { code: 'no_txt_at_name'; queriedName: string }
  | { code: 'appended_zone_suspected'; queriedName: string; foundAt: string }
  | { code: 'value_mismatch'; expected: string; found: string[] }
  | { code: 'token_expired'; expiredAt: Date }
  | { code: 'nameservers_unreachable'; attempted: string[]; timeoutMs: number }
  | { code: 'zone_not_found'; walked: string[] };

DomainClaim is live, and the demo names reach every failure above. Designed and not built yet: checking on a schedule while nobody has the claim open, the grace window and the email behind it, transfers between accounts, and a second vantage point.