Multi-Doctor Dental Rebuild, 64 Hours Delivered
Dual-practitioner dental WordPress rebuild with dedicated bio pages — 64 hours in 17 days, spec followed line-for-line, 48-item launch checklist closed.
Screenshots captured by automated tooling — some elements may not have loaded fully or may layer on top of each other. For the most accurate view, visit the live site →
Rebuild the site on a new stack. Implement the spec. Don't improvise. Hand it back ready for cutover.
Client (end user): Brightworks Dentistry — Dr. Preston Shurley and Patrice Robbins
Engagement: White-label development for a US marketing agency
Delivered: January 2025 · 17 days · 64 hours · on schedule, no overrun
The Craft of a Rebuild
A two-practitioner dental WordPress rebuild — dedicated bio pages for Dr. Preston Shurley and Patrice Robbins sat alongside service pages, each a distinct content type, making template completeness across every URL the binding constraint. We shipped the full Elementor Pro rebuild in 17 days, 64 hours, and a per-content-type verification pass surfaced both practitioner pages on the old styling, closed in a retained sprint.
This case study is a record of one such rebuild, in which the agency owned the strategy and we owned the execution.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — General Dentistry |
| End-client | Brightworks Dentistry (Dr. Preston Shurley and Patrice Robbins) |
| Engagement | White-label WordPress build for a US marketing agency specialising in local-business websites |
| Project Type | WordPress rebuild with Elementor Pro on WP Engine |
| Scope | Full site — services, multi-doctor team pages, blog, contact forms, PDF downloads |
| Timeline | 17 days (27 Dec 2024 – 13 Jan 2025), on schedule |
| Effort | 64 hours against a 64-hour estimate — no overrun |
| Team | 5 specialists (dev · QA fixes · PM) |
| Tech Stack | WordPress · Elementor Pro · Gravity Forms · WP Engine · Yoast · Screaming Frog · Site Checker (xaverPRO QA plugin) |
| Content parity check | Original-vs-rebuild content diff cleared before handoff — no missing copy, no broken internal links, no structural drift |
| Delivered | Spec followed line-for-line — redirects, meta titles, PDF library, multi-doctor team pages, 48-item launch checklist |
| Review rounds | ≈2 review rounds across the 17-day calendar window |
| Per-ticket effort | 5 internal Redmine tickets · median 1h / P75 64h per ticket |
The Brief
Brightworks Dentistry is a two-practitioner dental office. The agency had been managing the practice’s web presence and needed the existing WordPress site rebuilt on a modern Elementor Pro stack — tighter templates, reliable Gravity Forms integration, and a PDF download library that had been grafted onto the old site with workarounds. The rebuild was a same-CMS project (WordPress to WordPress), which looks simpler than a platform migration on paper.
The agency handed us a Google Sheets workbook covering every URL to migrate, every meta title and description to preserve, every template to apply, and a detailed launch checklist. The ask was precise: execute the spec as written, stay outside the client-facing loop, deliver on the quoted hours. The agency’s project lead remained the visible vendor throughout. We worked inside their coordination system.
The risk the agency was hedging against was not ranking loss — the SEO strategy was theirs and it was already handled. The risk was handing a multi-practitioner rebuild to a dev team that treats a same-CMS project as a low-stakes exercise. Same-CMS rebuilds carry a specific failure mode: because the destination platform is familiar, a team that improvises can quietly rewrite a meta title, re-route a form, or skip a redirect that doesn’t look important. On a single-doctor site, one missed page is a missed page. On a site with two practitioners, each of whom has dedicated bio and team pages that patients navigate directly, partial template application is a less visible but equally damaging outcome.
Risk context. A same-CMS rebuild on a two-practitioner site produces a specific blind spot: the practitioner bio pages —
/team/dr-preston-shurley/and/team/patrice-robbins/— are their own content type, and a build pass that covers service pages without explicitly templating each doctor page leaves those URLs carrying the old site’s styling, visually intact on a Screaming Frog crawl but wrong. Dr. Shurley and Patrice Robbins each had dedicated team pages that were among the most visited non-service URLs on the legacy site — the kind of page patients share with family members and referrers land on. A rebuild that applies new templates correctly to service pages but leaves practitioner bio pages carrying the old site’s styling doesn’t look broken on a site-wide crawl; it surfaces in the agency’s QA pass, costing an unplanned correction sprint. This was not a hypothetical — during AM QA both doctor pages were still carrying the old template, logged as a dedicated fix ticket before cutover. The discipline here was treating every content type, not just the high-traffic one, as in-scope for complete template application.
How We Did It
1. Template-first build. Rather than rebuilding the full site page by page, we collapsed it into reusable templates applied across all content types:
- Homepage, About, Contact, and a Default fallback
- Services Lander + Service Page template powering the full service catalogue
- Doctor/Team Page template applied to each practitioner — Dr. Shurley and Patrice Robbins each with a dedicated, consistently styled bio page
- Blog template for ongoing content
- PDF library page — downloadable patient education resources integrated directly into the page structure rather than as external links
Templates covered every content type. Future edits live in one place per page type. We chose templates over per-page builds because the two-practitioner structure with dedicated bio pages made cross-page consistency the binding constraint — a constraint the agency’s page-level spec implicitly relied on but did not explicitly guard against.
2. Spec followed line-for-line, from the agency’s sheet. The agency’s Google Sheets workbook carried every URL, every meta title and description, every template assignment, and every integration note — including PDF file placement and Gravity Forms targets. We implemented each row as written. Where the sheet had a value, that value landed on the new site. Where it didn’t, we flagged back to the agency. No creative interpretations shipped.
The principle behind this is simple: on a rebuild, the spec is the contract between the agency and its client. A dev team’s job is to protect that contract, not to edit it.
3. Crawl-based verification, not “looks fine to me”. Before DNS cutover, we ran Screaming Frog on the old production site and the staging rebuild side-by-side. Status codes, broken links, redirect chains, meta-tag differences — every delta reconciled against the agency’s spec. A second crawl after go-live confirmed every internal link resolved on the live domain. The comparison also confirmed PDF download paths were correctly wired and the practitioner bio pages were on the new template.
4. 48-item launch checklist, closed before handoff. Categories covered design fidelity, functionality (forms, downloads, navigation), content accuracy, SEO and analytics, responsive display across six viewports, and a Domain and DNS migration sequence to WP Engine. Cross-device QA ran on Chrome, Firefox, Safari, and Edge. Nothing shipped until each line was signed off.
The Doctor/Team Page template was the discipline that kept the two-practitioner structure from splitting along content-type lines. Without an explicit template per bio page, those URLs carry the old site’s styling after every service page takes the new design — exactly what happened during AM QA and why issue #233 existed. Templating every content type, not just the high-traffic ones, was the constraint the spec implied but did not enforce.
Results
| Metric | Outcome |
|---|---|
| Spec fidelity — redirects | All legacy URLs redirected as specified |
| Spec fidelity — meta data | All meta titles and descriptions placed as specified |
| Spec fidelity — templates | Complete template system built and applied site-wide, including practitioner pages |
| Spec fidelity — PDF library | Patient education PDFs uploaded and correctly linked on applicable pages |
| Launch checklist | 48 / 48 items signed off before cutover |
| Timeline | 17 days, delivered on schedule |
| Effort | 64h / 64h estimate — no overrun, no scope creep |
| Responsive verification | Zero layout issues across 4 browsers × 6 viewports |
| Internal QA | All agency-scoped issues closed before handoff; post-launch agency QA round addressed form and review-link corrections in a retained sprint |
| Handoff | Site live on WP Engine on the scheduled cutover day, no downtime |
| Site status | brightworksdentistry.com still live in production |
The outcome, restated plainly: the agency’s spec was implemented as written, inside the quoted hours, on the scheduled cutover day. A retained sprint after the agency’s post-launch QA pass closed additional items — the build held its shape through that process.
Operational Integrity at handoff
The parity diff between the legacy site and the staging rebuild caught that /team/dr-preston-shurley/ and /team/patrice-robbins/ were still rendering the old site’s design — every other page had taken the new template, only those two URLs had slipped — and both were logged as a dedicated fix ticket before cutover (issue #233). Pre-handoff QA ran through Site Checker — see our QA discipline for the categories and the fail-zero gate. The agency’s own QA layer — their tools, their process — ran post-handoff and surfaced issues into the shared backlog for our fix loop until they signed off.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | 1 day | Agency spec reviewed; 64h quoted and agreed |
| Development | ~12 days | Full site rebuilt across all templates including practitioner bio pages |
| Internal QA & review | 3 days | Issues logged; all agency-scoped work cleared before handoff |
| Spec verification | 1 day | Meta, redirects, and PDF paths reconciled against workbook |
| Delivery & DNS cutover | 1 day | Site live on WP Engine, no downtime |
Phases overlap (QA ran alongside late development), which is why the calendar timeline is 17 days rather than the sum of individual phases.
Team
Delivery team
- Nikita Tumasevic — lead developer (full site build and template system, including multi-doctor team pages)
- Anna Polunina — implementation support and QA across the rebuilt pages
- Alexey Melkov — implementation support
- Ivan — supporting developer (repeating blocks and page duplication)
- Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)
Agency-side project management and SEO strategy remained with the partner agency throughout. The agency stayed the visible vendor; our team was invisible to the end client at every stage of the build and cutover.
For agencies considering a white-label WordPress build
If your agency has had a rebuild come back with some pages still on the old site’s styling — practitioner bios, team pages, secondary content types the dev team didn’t explicitly template — that’s the failure mode a same-CMS project makes easy to miss. Send us your sitemap workbook and template assignment list; we will review it for content-type coverage gaps and return a fixed-hours quote within 24 hours. No cost. No obligation to proceed.
Don't have a spec yet? Send a one-paragraph description — we'll come back with the questions worth asking. Send a description →
Site Checker runs before the agency sees anything.
Before handoff, every staging build runs through Site Checker — the WordPress QA plugin we built and maintain. It is a fail-zero gate: nothing goes to the agency with an open failure. Warnings are reviewed and judged non-blocking; the agency gets a clean slate to run their own QA layer against, not a staging site with known issues in the queue.