Multi-Location Dental Rebuild
A multi-location dental rebuild shipped to spec in 17 days — 65 hours, two clinic locations with Dentrix Ascend booking, 8 review rounds, no overrun.
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): Sonrisa Family Dental — Multi-location family dentistry, Chicago, IL
Engagement: White-label development for a US marketing agency
Delivered: May 2025 · 17 days · 65 hours · on schedule, no overrun
The Craft of a Rebuild
Forty-five hours of development over seventeen days for a dual-location Chicago dental practice — two clinic storefronts, two sets of Dentrix Ascend booking links, and a sitemap that grew mid-build when the agency surfaced blog URLs and location sub-pages absent from the original tracker. We built to the spec as it firmed, deferred the undefined, and confirmed every scope gap before touching code.
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 — Family Dentistry |
| End-client | Sonrisa Family Dental (multi-location practice, Chicago, IL: Little Village — Pulaski · Little Village — Esperanza Health Center) |
| 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, location pages, booking integration, patient resources |
| Timeline | 17 days (28 Apr – 15 May 2025), on schedule |
| Effort | 65 hours against a 65-hour estimate — no overrun |
| Team | 3 specialists (45h dev · 10h PM · 10h QA) |
| Tech Stack | WordPress · Elementor Pro · WP Engine · Dentrix Ascend booking embeds · Gravity Forms · 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 — full site rebuild, per-location booking links, launch checklist completed |
| Review rounds | ≈8 review rounds across the 17-day calendar window |
| Per-ticket effort | 11 internal Redmine tickets · median 6h / P75 14h per ticket |
The Brief
The agency had a retained dental client operating two Chicago clinic locations — a practice that serves Spanish-speaking communities in the Little Village neighbourhood under the name Sonrisa Family Dental. The existing site needed a full WordPress rebuild on WP Engine. The agency had completed the strategic work: a Google Sheets workbook titled “Website Redesign Progress Tracker” containing every URL to migrate, every meta title to carry forward, and a launch checklist.
The ask was specific. Take the spec as given; rebuild the site on Elementor Pro; hand it back ready for cutover. Remain outside the client-facing loop. Implement the SEO decisions as written. Deliver within the quoted hours.
One dimension of this rebuild added surface area that a single-location dental practice does not carry: the site had to serve two distinct clinic addresses simultaneously. The booking flow — using Dentrix Ascend direct-booking links — resolved to a different appointment system per location. Each location link had to land at the correct clinic. If the wrong Dentrix Ascend parameter was bound to a location’s booking button, the patient would arrive at a form routing to a different practice.
The spec was also refined mid-build: the original workbook did not include the services lander (/services/), the locations lander (/locations/), or the library/blog lander (/library/). The agency confirmed mid-build which of these to include, which to defer, and which to implement as-is. We held position until that confirmation arrived rather than interpreting intent. No creative decisions were made on our side; every structural choice was the agency’s.
Risk context. A multi-location dental practice that serves a specific community carries a different kind of risk at rebuild time than a single-location general practice. The booking flow is not one conversion path — it is two, one per clinic. Each location’s Dentrix Ascend link embeds a site-specific patient identifier; bind the wrong identifier to the wrong clinic address and the site functions visually while routing patients to the wrong appointment queue. The failure is silent at QA time (the button fires, the form loads) and apparent only when a patient shows up at a clinic that has no record of them. Verifying the booking integration by location, against the spec, is not optional.
How We Did It
1. Template-first build. Rather than rebuilding every page individually, we built a template system appropriate for a family dental practice serving two locations:
- Homepage and Contact Us — the entry and conversion pages
- Services Lander + Service Page — service taxonomy powering all individual treatment pages
- Location Page — the multi-location-specific template powering both clinic pages (Pulaski address; Esperanza Health Center address), each carrying its own Dentrix Ascend booking link
- About, Blog Lander, Default Template — supporting pages per the spec
The location template was the load-bearing piece: it had to carry NAP-accurate information (address, phone, maps link) for each clinic independently, with the correct booking embed per location.
2. Spec followed line-for-line, from the agency’s sheet. The agency provided a Google Sheets workbook tracking every URL to migrate, every meta data requirement, and a launch checklist. We implemented each row as written. When the initial spec had gaps — three lander pages (/locations/, /services/, /library/) that were not yet in the sitemap — we surfaced that to the agency and held on those pages until explicit direction was given. The services lander was built; the library lander was deferred at the agency’s instruction.
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 interpret 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, redirect chains, and internal-link resolution — every delta reconciled against the agency’s spec. Particular attention was paid to the booking links: each location’s Dentrix Ascend URL was verified against the parameters specified in the brief. A second crawl after go-live confirmed every internal link resolved on the live domain.
4. Launch checklist completed before handoff. The agency’s launch checklist covered pre-migration validation across all categories: Design, Functionality, Content, SEO & Analytics, Responsive behaviour, integration verification (Dentrix booking per location, Gravity Forms email routing, GA/GTM carryover), and a DNS migration to WP Engine. Cross-device QA on Chrome / Firefox / Safari / Edge and six viewports (1920 / 1280 / 1024 / iPad / mobile portrait / mobile landscape).
The discipline that mattered was holding position when the spec had gaps. Three lander pages — /locations/, /library/, /services/ — were absent from the original workbook mid-build; we surfaced them to the agency and built nothing on those pages until direction arrived. The booking links followed the same rule: each location’s Dentrix Ascend parameter was confirmed from the spec before it was bound, not assumed from context.
Results
| Metric | Outcome |
|---|---|
| Spec fidelity — site build | Full site rebuilt per workbook spec — all pages, all meta data, all integrations as specified |
| Spec fidelity — booking integration | Per-location Dentrix Ascend booking links verified against spec — Pulaski and Esperanza Health Center routes confirmed |
| Spec fidelity — redirects | All redirect requirements from the workbook implemented as 301s |
| Timeline | 17 days, delivered on schedule |
| Effort | 65h / 65h estimate — no overrun, no scope creep |
| Responsive verification | Zero layout issues across 4 browsers × 6 viewports |
| Internal QA | All agency-scoped backlog items closed before handoff |
| Handoff | Site live on WP Engine on the scheduled cutover day, no downtime |
| Site status | sonrisafamilydental.com still live, still indexed by Google |
| Retained engagement | Post-launch refinements including homepage redesign — each delivered in additive sprints inside the same agency relationship |
The outcome, restated plainly: the agency’s spec was implemented as written, inside the quoted hours, on the scheduled cutover day.
Operational Integrity at handoff
The parity diff caught two URL path inversions — pages at /invisalign/services/ while every other page in that section followed /services/invisalign/ — and the per-location Dentrix Ascend booking links were verified against the two distinct pid parameters specified in the brief (ASC2000000000958 for Pulaski, ASC2000000000895 for Esperanza Health Center) before the build left staging. 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; 65h quoted and agreed |
| Development | ~12 days | Full site rebuilt across templates on WP Engine staging |
| Internal QA & review | 2 days | Backlog items addressed; location booking links verified |
| Spec verification | 1 day | Redirects, meta data, booking integrations reconciled against sheet |
| 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)
- Pavel Sazhin — QA and post-launch fix implementation
- Anna Polunina — project coordination, scope confirmation against the workbook
- Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)
Our team stayed invisible to the end client throughout the engagement. All decisions on which pages to build, which locations to include, which booking links to use, and how to handle pages absent from the initial spec belonged entirely to the agency — we communicated through the agency, not directly with the dental practice.
For agencies considering a white-label WordPress build
First engagement with a multi-location dental client is a calibration batch — typically one or two locations at fixed hours, with per-location booking integration verified before handoff. If your agency manages a retained dental client across multiple sites, send a current migration brief with the booking-integration spec. We will review it for per-location integration risk, identify gaps before kick-off, and return a fixed-hours estimate within 24 hours. No cost, no obligation.
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.