Domain portal: from a reseller account to an automated domain business, built with an AI agent team
How I used parallel Claude Code sessions, a coordinator and a review board of agent roles to build and run a domain portal from order to invoice, and which rules made the agent team safe to work with.
Since 24 October 2026, chnet.domains has run a domain business I don’t operate by hand: customers search for a domain, order it, pay, receive their invoice and manage their domains in a portal. On 26 October the first registration went through fully automatically, without me pressing a button. I built and run it not with developers but with a team of AI agents. This post is about that way of working; the billing architecture gets a post of its own.
Starting point
Via a reseller account with a hosting provider I manage client domains, including one long-standing client with around 70 of them. The process spanned three systems: registration ordering, technical domain administration and accounting. By my own estimate every client request meant about an hour of clicking, invoices were created by hand as recurring invoices, and clients had no view of their own portfolio.
So the goal was not “a nice portal” but order to registration without an admin, with the human handling only exceptions. For a one-person consultancy that is not a side project you start the classic way. With an agent team it was realistic, provided the team had rules that made it safe.
Solution
The product. A landing page with domain search and AI-assisted name suggestions, a customer portal with login, and a serverless backend defined entirely in AWS CDK: Lambda functions, DynamoDB, Cognito for sign-in and Step Functions for the long-running processes. An order can take days while it waits for a payment, a review or the registry; task-token wait states pause the workflow until an external event resumes it. Customers pay by card via Stripe or via PayPal; invoices are created in Lexware Office. The name suggestions come from a small model on Amazon Bedrock, protected by a guardrail, a hard budget cap and a golden eval as a release gate: a new prompt or model version ships only if it passes a fixed set of reference cases.
Every write call to the registrar costs money, even a failed one. How the portal is protected against duplicate billed calls is the subject of a separate post.
The team. The work was done by several parallel Claude Code sessions, which I call “lanes”. Each lane has a fixed topic, such as payments, domain settings or the landing page, and works in its own git worktree. That keeps lanes out of each other’s way on disk; each delivers its work as its own pull request.
Above the lanes sits a coordinator session. It serialises merges and deploy triggers and gives each lane an explicit GO before anything lands on the main branch. Another session is the interface to the human, that is, to me. I hardly talk to the lanes directly; questions, decision proposals and approvals go through this single point of contact.
Plans and larger changes are reviewed by a board of agent roles: architect, security, senior developer, FinOps and a sceptic. This is not a ritual. The first concept review turned the build plan around: the sceptic pointed out that the real pain was forgotten billing, not missing self-service. So an admin version with automated billing came first, then customer login, then ordering.
Guardrails
Agents write code fast. The real work was finding rules under which I can trust that pace. These proved themselves:
- The human decides on money, legal and anything public. Paid actions, legal texts and published copy only go out with my explicit approval. Everything else the lanes do on their own.
- Switches instead of deploys. New features ship inactive and are enabled via runtime switches in the configuration. A switch flips in seconds, and back; a deploy does not.
- Dry run by default. Every operator script first shows what it would do; writing requires an explicit flag.
- A local quality gate before every push. SonarQube checks the code locally before it leaves the machine, and each pull request gets exactly one push. That saves CI runs and stops lanes leaving each other red pipelines.
- After an abort, check the server state first. An aborted command is not a command that did not run. Before any retry, check what actually happened.
- One gate to the main branch. Only the coordinator releases merges and deploys, one at a time, and only after the previous run has been verified.
Outcome
The first portal commits date from 16 October 2026; it went live on 24 October, and the first fully automatic registration ran on 26 October. In that time around 300 pull requests for the portal and the landing page were merged into the main branch. Customers now manage their domains, DNS records and redirects themselves and download their invoices from the portal.
Still open: there is no direct debit yet, and customers cannot yet change their name servers themselves. Automatic registration currently covers a single domain extension; more will follow after their own test registrations.
What did not go smoothly
- Coordination has a cost. The coordinator is a deliberate bottleneck, but still a bottleneck. Lanes waited for their GO while another verified its deploy. Parallel coding is not parallel rollout.
- Merges crowding each other out. The CI keeps only the newest waiting deploy per branch. If two merges follow each other too quickly, it silently discards the older waiting deploy. That is exactly why everything goes through the coordinator, my own merges included.
- Shared tools. Several lanes share one SonarQube instance. A local scan running at the same time as the scan on the main branch could make that one fail. The fix: before every scan, check whether a run on the main branch is in progress.
Transfer
The pattern is not tied to domains. It fits wherever a small team, at the extreme a single person, wants to build and run a product with real money flowing through it:
- Fixed lanes in their own worktrees can be adopted one to one. What matters is a clearly scoped topic per lane, so that conflicts stay rare.
- A coordinator for the main branch makes sense in any team with more than one agent session as soon as deploys are tied to merges.
- A single interface to the human keeps the number of questions manageable. Decide up front which decisions stay with the human: for me, money, legal texts and publications.
- A review board of roles pays off above all for concepts; the most valuable voice was often the sceptic’s.
What does not transfer one to one is the level of trust. In a company with existing approval and operations processes, switches, dry runs and approvals have to hook into them rather than replace them. The principle stays the same: agents get the pace, humans keep the decisions that have consequences.
Stack: Claude Code · AWS CDK · AWS Lambda · AWS Step Functions · DynamoDB · Amazon Cognito · Amazon Bedrock · Stripe · PayPal · Lexware Office · Astro · SonarQube