27-Page Multi-Office Dental WordPress Build

Client (end user): Alta Dental Group — Irvine, CA
Engagement: White-label development for a US marketing agency
Delivered: May – Sep 2025 · 140 days · 63 hours across build and fix-and-feedback phases

The Craft of a Build

A 27-page multi-office dental build to a Figma design system — two practices under one brand, one domain, distinct phone numbers per location. A phone button that dialled only one office on mobile was not a minor inconsistency: it was a lost conversion point. The engagement ran 63 hours across 140 days, working through two parallel QA backlogs — 75 SEO issues flagged by the agency and 29 CX items.

This case study is a record of such a build — a multi-office dental group in Irvine, CA, delivered for a US marketing agency specialising in local-business dental clients.

Snapshot

The Brief

A US marketing agency retained by Alta Dental Group — a multi-office dental practice in Irvine operating under a single brand — handed over a Google Sheets workbook with a full URL map, a Figma design file, a templates catalogue, a launch checklist, and pre-populated QA backlogs. The build ran on their WP Engine environment; the page builder was Elementor; forms ran through Gravity Forms. The Figma design carried the full brand specification, including a scroll-transition animation reference the client had flagged before build-out began.

The ask: build 27 URLs across the agency’s standard dental template library, apply the Figma design spec across all pages, populate service-page content from agency-provided copy, and work down two parallel QA backlogs — an SEO-track backlog and a CX-track backlog — until the agency accepted the site. Throughout, remain outside the end-client-facing loop; surface ambiguity back to the agency; do not improvise content, navigation, or location-routing decisions.

How We Did It

1. Nine templates, 27 pages, one build pipeline. Alta Dental Group’s pages spread across the agency’s standard dental template library: Homepage, About Us (2 pages — team landing and a secondary about page), Contact Us, Services Lander, Service Page (17 individual service pages including emergency dentistry, dental implants, cosmetic dentistry, bone grafting, and specialist procedures), Doctor Page (4 individual physician profile pages), Location, and a Default Template for the insurance page added mid-engagement. Each page was built on its assigned template from the sitemap row; no page was hand-rolled outside the template system.

2. Spec followed line-for-line — including the per-page Hours Estimated column. The agency’s workbook carried an Hours Estimated value for each sitemap row — the Homepage at 12h (the heaviest individual row, reflecting the animation specification), the About / Our Team page at 3.5h, and service pages at 0.5h each once the initial content corpus was established. We implemented against those values. The 12-hour Homepage row was the load-bearing piece: the Figma design referenced scroll-transition animations the client had flagged, and implementing those cleanly inside the Elementor stack required additional iteration that the row budget anticipated.

The principle: on a build with a pre-costed sitemap, the workbook is the contract. A dev team’s job is to deliver inside the row-level budgets, not to re-open the pricing conversation when a complex page takes more calendar time than a standard template page.

3. Service-page content batches absorbed mid-engagement. The initial sitemap carried placeholder estimates for service pages pending agency-provided copy. Two separate content batches arrived across the engagement window — first a partial set that drove the initial service-page build, then a second batch that required re-opening completed pages for content integration. Both batches were absorbed through dedicated Redmine tasks, worked down without extending the budget, and each resulting page returned to the QA backlog for a second pass before the agency accepted it. We chose to absorb the late content within the original estimate rather than request a timeline extension, because the budget had been sized to accommodate iterative client feedback — reopening the schedule for every content drop would have undercut the fixed-hours model the agency had bought into.

4. Two-office contact routing verified at handoff. Late in the engagement, the QA backlog surfaced a routing issue: the mobile phone button defaulted to a single office number. The fix was not cosmetic — it required a two-office selection popup to be wired into the mobile navigation header, matching the desktop “Call Us” modal already in place. The issue moved through two QA cycles before the agency accepted the implementation, and the insurance page added to the menu simultaneously was closed through the same QA pass.

5. Two parallel QA loops, closed before launch. Issues were tracked in two agency-side backlog tabs — the Issues Backlog(SEO) (75 rows) and the Issues Backlog(CX) (29 rows). Of the 75 SEO items, 73 closed as Completed before data export; 1 remained Info Needed and 1 as To Do, both awaiting agency input. Of the 29 CX items, 26 closed as Completed; 1 was still In Progress and 2 were Info Needed at data export. The 39-row launch checklist — Design, Functionality, Content, Pre-Migration, and Post-Migration columns — was signed off before the production go-live.

The 12-hour Homepage row — the heaviest in the sitemap, carrying the scroll-transition animation spec — set the pacing logic for the rest of the build: resolve the most complex page first, then absorb the service-page content batches against the remaining rows. Working that order meant two content drops and a two-office mobile routing fix closed within the original 63-hour estimate.

Results

Operational Integrity at handoff

The CX backlog row 30 carried the highest-stakes routing finding of the engagement: the mobile top-right phone button was wired to only one office, so a two-office selection popup had to be built and linked to match the existing desktop “Call Us” modal — a gap that would have sent patients to the wrong location at call time. 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

Phases overlap — content integration batches arrived while the initial QA pass was underway, which is why the calendar is 140 days rather than the sum of individual phases.

Team

Delivery team

• Nikita Tumasevic — lead developer across build and fix-and-feedback phases
• Pavel Sazhin — project management and QA iterations
• Anna Polunina — developer support on service-page content integration and QA rounds
• Timur Arbaev — QA iterations and fixes
• Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)

Agency-side project management and client-facing communication remained with the partner agency throughout. Our team was invisible to the end client.

For agencies commissioning a white-label WordPress build