This site replaced a WordPress site. Before the first new page was designed, the old one was crawled and classified, and a private Command Center was built to route the work, hold the evidence and refuse to let a builder approve its own output.
What follows is the record, with the numbers as they were measured rather than as they would read best.
URLs crawled and classified
88
URLs crawled and classified
digitalboutique.ai, 2026-08-27
agent roles, nine of them staffed
12
agent roles, nine of them staffed
records in the build system; nine have a definition file
routes at launch
20
routes at launch
all returning 200, one h1 each
dead internal links
0
dead internal links
final QA, in either direction
The starting point
Start with the system, not the redesign.
The goal was never to convert a theme. The existing site was treated as source material: every page, offer, funnel, factual claim, form and article had to be understood before anything replaced it.
digitalboutique.ai runs on WordPress with eight plugins — Elementor and Elementor Pro for layout, Fluent Forms for capture, WooCommerce and WooCommerce Payments for the shop, a security plugin, a media organiser and Google Site Kit. It is a working site. It is also a stack where the page, the form and the checkout each belong to a different vendor.
The audit was read-only. No form was submitted, no destination was touched, and the sister domain was left alone.
digitalboutique.ai
digitalboutique.ai — the previous operating state, captured 30 August 2026.
dbai.agency
dbai.agency — the same region of the page, captured at the same width.
The audit
88 URLs before one new page.
A public crawl — sitemap, robots and internal-link traversal — using 99 of the 800 requests it was allowed. Every URL it found was classified before any of them was replaced.
What the crawl found
URLs discovered
88
returned 200
84
returned 404
4
meaningful pagesstatus 200, excluding archives and media
68
How every one was classified
KEEP
33
REMOVEincluding 16 taxonomy archives and 11 placeholder pages
31
REWRITE
18
REDIRECT
4
MERGE
2
The five classifications sum to 88, not to 68: every discovered URL was classified, including the four that answered 404. The 68 is a second reading of the same crawl — the pages that carried meaning. Presenting these as one funnel would be tidier and wrong.
The crawl also produced a content truth matrix. It recorded eight claims the old site contradicted itself on, and six more that could not be verified from any source available. Those claims are not repeated here, and they are not on this site: the same list is compiled into the build, and a page that tries to publish one of them fails to build.
The operating layer
Before we rebuilt the site, we built the system that would rebuild it.
Claude Code did the work. The Command Center — a private Next.js application on Neon Postgres — held the state: phases, page status, agents, sessions, tasks, deliverables, design decisions, reviews, QA, SEO, commits, deployments, blockers and launch readiness.
A coding session ends and takes its context with it. The build needed something that did not: a place where a task's history survived the session that produced it, and where a claim could be checked against a record rather than remembered.
It is a separate repository from the site, on a separate host, behind authentication. The public site has no dependency on it — no shared database, no admin surface, nothing that would put a control plane inside a marketing page.
What it held
Project phases
Page status through ten stages
Specialist agents and their sessions
Tasks and deliverables
Design decisions
Blockers
QA runs
Security checks
SEO and redirect mapping
Token usage
Commits
The ten stages a page moves through
AUDIT→
STRATEGY→
COPY→
WIREFRAME→
DESIGN→
BUILD→
RESPONSIVE→
QA→
SEO→
APPROVAL
Ninety-two pages sit in that matrix, most of them old-site URLs carried in by the audit and never built. Thirteen are approved. The dashboard reports that as thirteen of ninety-two rather than as a percentage of the pages that shipped, which is the less flattering of the two true numbers.
build.dbai.agency · activity
The event stream, filtered to stage changes. Every page's passage through the ten stages is a recorded event with a timestamp.
The team
Twelve roles. Nine that could run.
The build system holds twelve agent records. Nine of them have an executable definition — a scope, a set of tools and a rule about what that agent may not do — identical in both repositories. The other three are the gap between the org chart and the org.
01
Orchestrator
Sequences the work, verifies plan claims before dispatch, rules on conflicts, keeps the ledger. Writes no production code.
02
Content migration
Sources copy from the audited material and checks every claim against the truth matrix. Raises blockers rather than inventing replacements.
03
Brand director
Resolves genuine design-system gaps. Never creates new visual directions.
04
Frontend architect
Owns shared primitives and site-wide architecture. Invoked only when a page cannot be built from what exists.
05
Page builder
Builds one page or a tightly-related group. Implements, self-tests, reports — never approves its own work.
06
Code reviewer
Reviews a diff it did not write, against requirements it receives separately.
07
QA and performance
Runs the suite and exercises the page in a real browser at five widths. Reports results exactly as they occurred.
08
Visual reviewer
Judges design-system compliance, hierarchy, spacing and motion — in a browser, at real widths.
09
SEO migration
Checks metadata, canonical, structured data, internal links and redirect mapping.
Three of the twelve never got a definition file. Site Auditor and UX / Conversion were seeded into the roster in the first phase and the work went to prompts and scripts instead; the security agent is a scheduled job rather than something that takes a task. A roster is a plan, and this one records where the plan and the build diverged rather than quietly matching them up afterwards.
Site Auditor
The audit ran as a phase, from its own prompt and its own scripts.
UX / Conversion
Information architecture and conversion paths, absorbed into the brand and page-builder roles.
Security agent
A scheduled check rather than an agent that claims work.
The review system
The builder could not approve its own work.
Every page moved through the same sequence, and no stage could be skipped by the agent that would benefit from skipping it.
01
Build
A page builder implements against a written requirement, self-tests, and reports what it did.
02
Code review
A reviewer that did not write the diff receives the requirements separately and returns a spec verdict and a quality verdict.
03
Fix
Findings go back to the builder. The reviewer re-reviews; it does not fix.
04
QA
The suite, plus a real browser at 1440, 1280, 1024, 820, 390 and 320.
05
Visual review
Design-system compliance, hierarchy, typography, spacing and motion behaviour, judged on screen.
Only then does the orchestrator mark the work done.
Builder and reviewer are different agents with different definitions, and the reviewer is given the requirements rather than the builder's account of them. That distinction is the whole mechanism: a reviewer reading the builder's summary is reviewing the summary.
None of this is a record type. The build system holds no review object, no verdict field and no findings table, and a page claiming otherwise would be describing a screen that does not exist. What holds the line is narrower and duller: two agent definitions that say an independent gate never reviews its own work, and a run ledger where a gate can return FAIL against work already written.
One pair of rows is the whole argument. At 11:40:11 the links gate returned FAIL against a build that was already finished — forty untracked conversion anchors, found by crawling the built site rather than by any test. At 11:40:12 it returned PASS on the fix. A gate that cannot return FAIL is decoration; this one did, one second before it did not.
build.dbai.agency · qa run history
The run ledger, 29 August. An independent gate returning FAIL against finished work at 11:40:11, and PASS on the fix one second later.
What the system caught
The interesting part is what failed.
A quality system is only worth describing if you say what it found. These are documented, and two of them are defects in the quality system itself.
01
Forty untracked conversion anchors
The analytics guard walked every anchor inside <main>. The footer sits outside <main>, names the contact page twice, and renders on all twenty routes.
Two anchors × twenty routes. On several pages the footer carries the only Discovery Call link there is, so those clicks were reaching the form and reporting nothing.
A guard written expressly to stop “we only checked one region” was itself scoped to one region. It was found by crawling and counting, not by a test.
02
The conversion button failed contrast — in the approved design system
The primary button measured 3.52:1 at rest and 2.37:1 on hover against a 4.5:1 requirement. The hover state was worse than the rest state.
It was not a defect in a new page. It was in the design system every page had already been built from, and it was on the site's only conversion control.
Approval is not verification. It now measures 5.35:1 and 4.71:1, recomputed independently three times.
03
A test that could not fail
The contrast suite computed hover ratios from the CSS custom properties rather than from what the browser painted.
Restoring the old hover fill would have left every token correct, every test green, and shipped a 2.37:1 button.
A green test can still be the wrong test. It now reads rendered output.
04
The skip link that never moved focus
Activating “skip to content” scrolled the page, but the next Tab returned to the header navigation, because the main landmark was not focusable.
It affected every page, had been there since the foundation commit, and had passed a foundation review and three QA gates.
Three gates checked that the link existed. None had checked what it did.
05
A record that described a fix as already done
A ruling was written after the work it governed had been built, and entered the Command Center in the past tense. The links it required to be removed were still live — on the contact page.
Anything reading the record would have reported the work complete. The QA gate tested the page instead, and found the contradiction.
A tracker that states an intention in the past tense is the exact failure this project exists to prevent. The dashboard records reality; it cannot stand in for checking it.
06
Review packets that were quietly incomplete
Three times, the file list handed to a reviewer was short — a module missed by a filter, a new test file, a change outside the given paths.
Each was caught because the reviewer noticed the builder's report described a file the diff did not contain.
The review system catching a defect in the review system. The packet is now derived from the repository state rather than assembled by hand.
The transformation
Eight plugins, then six dependencies.
The replacement is deliberately small. Everything the old stack delegated to a plugin is either code in this repository or absent by decision.
Before · WordPress
Elementor
Elementor Pro
Fluent Forms
WooCommerce
WooCommerce Payments
All-in-One Security and Firewall
WP Media Folder
Google Site Kit
8 plugins
After · Next.js on Vercel
Next.js App Router and React
TypeScript throughout
Tailwind and one design system
Zod-validated forms, server-side
A typed analytics layer
Statically rendered routes
6 layers, one repository
Six runtime dependencies at launch; nine today, the three additions belonging to a chat feature that is built and switched off. The comparison is fair only because both sides are counted the same way: things the running site loads that somebody else maintains.
One finding stands for the difference. On the old site, not a single form field on any page carried a required attribute — while the contact form marked eight of its eleven fields with a red asterisk. It displayed requirements it did not enforce. The replacement validates on the server, and reports success on exactly one path: a valid submission that a configured destination accepted.
Before
Eleven fields, eight marked required with a red asterisk. Not one field on the old site — on any page — carried a required attribute in the markup.
After
Five fields, each explaining why it is asked for, and the privacy policy linked inside the form rather than only in the footer.
Launch architecture
Two paths off the page, both of them checked.
The site is statically rendered. Only two things happen at request time, and each was verified end to end before launch.
Contact
Contact form→
Server validation→
Authenticated webhook→
Mail notification→
Truthful success or failure
The delivery adapter returns success on one path only — a configured destination answering 2xx. Everything else, including an unconfigured destination, is a failure the visitor sees. A form that swallows leads while showing a thank-you is the worst outcome available on that page.
Analytics
Page or CTA→
Typed event layer→
Vercel Analytics→
Speed Insights
Every event is a name in a closed union with an enumerated payload. There is no free-text field in any of them, so a visitor's own words cannot reach an analytics payload by accident — and a test asserts that no future field can be named in a way that would allow it.
Delivery was not assumed. The workflow platform reports success for runs that delivered nothing, so the launch gate was a message id returned by the mail provider with the message in the inbox. Never the status field.
The result
What launched, and what it measured.
Every figure below carries the scope it was measured at.
routes live
20
routes live
each returning 200 with exactly one h1
routes deliberately not shipped
5
routes deliberately not shipped
returning 404, linked from nowhere
dead internal links
0
dead internal links
whole document, all 20 routes, both directions
unwired conversion anchors
0
unwired conversion anchors
after the footer finding was fixed
tests against live production
48/48
tests against live production
16 tests × Chromium, WebKit, Firefox
Lighthouse accessibility
100
Lighthouse accessibility
five sampled production pages, zero failed audits
Lighthouse performance
98–99
Lighthouse performance
same five pages, 2026-08-29
largest contentful paint
2.0–2.4s
largest contentful paint
same five pages
The suite is dated because it moves. At launch it was 217 unit tests and 459 browser tests; the current build runs 309 and 476. A pre-launch figure presented as a final one is an interim wearing an outcome's clothes.
The SEO score rose from 66 to 100 with no code change. The single deduction was the crawl block that had been holding the site out of the index on purpose, and it cleared itself on the redeploy that lifted it. Nothing was tuned to chase a score.
Scope
Not everything that can ship should ship.
Decisions taken deliberately, and recorded so they could be argued with.
The old site was left running. No forced migration, no redirect cutover.
Four sections were deferred rather than half-built. Their routes return 404 and nothing links to them.
A client testimonial — the strongest quote in the entire audited source — was not used, because permission for it was never recorded.
A team member's job title was omitted, because the audited source gave two contradictory ones and choosing between them was not the build's decision to make.
Headline figures with no verifiable source were left out rather than replaced with plausible ones. Several sections that would normally carry a metric carry none.
Sequence
Four dates.
Dates, not durations. Version control does not reach the start of the project, so nothing here claims an elapsed time.
Audit complete
88 URLs crawled, 68 meaningful pages classified, the content truth matrix written.
Direction approved
Four homepage directions evaluated; the fourth approved and promoted to the benchmark. Both repositories begin.
Launch
The crawl block lifted, the site redeployed, indexing enabled, every launch gate passed.
After
Post-launch work continues under the same review system that produced the launch.
Why this is the case study
The site is the argument.
Every part of this is something DBAI builds for other people: an orchestration layer over specialist agents, a custom application holding the state, automated checks that gate the work, and a human approving the result.
The difference is that here the work product is public and the record is ours to show. The claims on this page can be checked against the site they describe.
Next
Build the operating layer behind your business.
If a website rebuild can be run this way, so can the work that actually costs your team its week — sales operations, support, internal knowledge, the handoffs between systems.
