Multi-Location Dental Rebuild, Shipped to Spec in 17 Days — White-Label Delivery for a US Marketing Agency
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.
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.
What follows traces a rebuild where the agency set the direction and our team carried out the build.
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 |
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 brief was narrow by design. Accept the spec at face value, rebuild on Elementor Pro, and return the site at cutover-ready state. No direct line to the practice, no second-guessing the SEO calls the agency had locked in, and no drift past the hours they had quoted.
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. We made no creative decisions 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. Building each page from scratch was the wrong economics, so we stood up a template system sized for a family practice running two clinics:
- 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 built to it row for row, without deviation. 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 the agency gave explicit direction. We built the services lander and deferred the library lander at the agency’s instruction.
It comes down to one idea: a rebuild’s spec is the contract the agency owes its client, and the developer’s role is to honour that contract rather than read intentions into it.
3. Crawl-based verification, not “looks fine to me”. Ahead of the DNS switch we put both the live production site and the staging rebuild through Screaming Frog at the same time and compared them. Wherever a status code, a redirect chain, or an internal link resolved differently, we traced the difference back to the agency’s spec and settled it there. The booking links got extra scrutiny: we checked each location’s Dentrix Ascend URL against the parameters the brief laid out. Once the site went live, a follow-up crawl proved every internal link still resolved on the production 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. QA went across Chrome, Firefox, Safari, and Edge, and through six screen sizes spanning 1920, 1280, 1024, iPad, mobile portrait, and mobile landscape.
What mattered most 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 |
| Site status | Live on WP Engine at https://sonrisafamilydental.com/. |
| Retained engagement | Post-launch refinements including homepage redesign — each delivered in additive sprints inside the same agency relationship |
The net of it: we shipped the agency’s spec verbatim, stayed under the hours they had quoted, and made the cutover date they had set.
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 we verified the per-location Dentrix Ascend booking links against the two pid parameters in the brief (ASC2000000000958 Pulaski, ASC2000000000895 Esperanza) before the build left staging. Our last pass before handoff went through Site Checker. Our QA approach sets out the categories and why an open flag keeps a site off the wire. After we handed over, the agency ran its own review and logged findings into the shared backlog. We cleared each item until the agency was satisfied.
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)
To Sonrisa Family Dental, the website was the agency’s work — our name reached the practice on no asset, no message, no login. 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 rebuild
On a multi-location practice rebuild, the booking integration ties conversion to a specific clinic address. For this practice — multi-location with separate booking streams; for others — single-location with a single funnel. The failure is silent: a patient triggers the location link and lands in the wrong queue. The redirect map misses rows — agency-ranked clinic pages return 404. Per-clinic schema drops out on import — rich results vanish.
The question is not “can you rebuild the site?” — it is “how exactly will you verify each location’s conversion path before cutover?”
Send us a current production URL, a draft redirect map, or your design files. We will audit the booking flow per location, trace every redirect row, and return a fixed-hours quote. Free, with a fixed quote in hours.
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.