86-Page Dental WordPress Build

Client (end user): Sopris Smiles — Englewood, CO
Engagement: White-label dental development for a US marketing agency
Delivered: January – February 2025 · 53 days · 51 hours across build and fix-and-feedback tail

The Craft of a Build

86 pages of an Elementor WordPress build to replicate a dental practice’s existing site, verified against a Screaming Frog three-crawl baseline — original, staging, and live — with all 86 URLs cross-checked for parity before launch. Delivered in 53 days at 51 hours, within a 50-hour row-level workbook estimate, a 45-item checklist closed, and an agency Issues Backlog worked to acceptance before handoff.

This case study is a record of such a replication build — delivered for a US marketing agency in the general-dental segment.

Snapshot

The Brief

A US marketing agency retained by Sopris Smiles — a general-dental practice in Englewood, Colorado — handed us a Google Sheets workbook with a full sitemap, a Screaming Frog crawl of the original site, a per-row Hours Estimated column, and a 45-item launch checklist. The existing site sat on an external host; the new build was staged on WP Engine. The page builder was Elementor; forms were Gravity Forms. The ask was to replicate the entire 86-URL surface on the new environment, preserving the original design language, meta data, and content structure, then work through the agency’s Issues Backlog until the build matched the original to the pixel and the crawl.

The risk the agency was hedging against was not whether 86 pages could be built — it was whether the dev partner would treat the original site as a faithful spec. An existing site is both the source of truth and a carrier of its own errors. The agency needed a partner that would replicate what was correct, surface what was broken, and fix it without introducing new drift. The brief was structured around exactly that concern: a line-for-line sitemap, a Screaming Frog baseline, and a staged fix loop after the first pass.

How We Did It

1. One custom template, 86 pages, one replication pipeline. Sopris Smiles’ entire site was built on the agency’s Original Design template — a single custom framework applied to all 86 URLs. The sitemap assigned the template to every row: 22 service pages, 50 blog posts, the homepage, about pages, technology, testimonials, financing, FAQ, contact, and blog-pagination pages. 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 every row. We implemented against that value. The homepage carried 10 hours; individual service pages carried 0.2–0.3 hours; blog posts carried 0.3 hours; the blog lander carried 2 hours. The aggregate came in at the agreed 50-hour estimate for the primary build, with the fix-and-feedback tail adding a marginal amount.

The principle behind this is simple: 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 page by page.

3. Screaming Frog baseline comparison across original, staging, and live surfaces. The workbook carried three Screaming Frog crawl tabs — the original site, the staging environment, and the new live site — plus a Compare Meta tab mapping old titles against new. We used these baselines to verify that every URL, title tag, and meta description from the original site was accounted for on the new build. Where the original had already contained errors — such as the teeth-cleaning page showing aligner content — we surfaced the discrepancy through the Issues Backlog rather than replicate it blindly. We chose crawl-based verification over manual page-by-page review because the Screaming Frog comparison across three environments — original, staging, and live — provided an auditable parity check across all 86 URLs that would have been impractical to reproduce by hand.

4. Two-track QA loop, closed through the fix-and-feedback tail. Issues were tracked in the agency’s Issues Backlog tab (14 rows, priorities from Medium to Urgent, spanning favicon, meta data, footer sanitization, video loading, blog H1 structure, trailing-slash discipline, and slug corrections). Of those 14 items, 7 closed as Completed before the initial handoff; the remaining items — including meta-title mismatches and a missing blog page — were resolved through the post-build fix-and-feedback tail tracked in Redmine. The 45-item launch checklist — Design, Functionality, Content, SEO and Analytics, Responsive, and Misc — closed behind both tracks.

Running Screaming Frog against all three environments in sequence — original, staging, live — before any content dispute was escalated meant every discrepancy was documentable. The teeth-cleaning page carrying aligner content was in the archive that way from the start; knowing that made the resolution a URL rename, not a contested rewrite. The crawl order was the method that kept the fix-and-feedback tail from becoming a negotiation.

Results

The outcome, restated plainly: the agency’s 86-URL dental build shipped on a single custom template inside the 50-hour quoted budget. The Screaming Frog baseline verified parity with the original site, the Issues Backlog and fix-and-feedback tail closed to agency-acceptance levels, and the launch checklist signed off before the site went live.

Operational Integrity at handoff

A pre-handoff link-check pass — run at Urgent priority — parsed all 86 URLs on the staging build and surfaced HTTP links still pointing to the staging hostname and a malformed tel: href where the display number (303-761-2999) did not match the href value (303-781-4440); both were corrected 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

Phases overlap — the fix-and-feedback tail began before the crawl-verification pass had fully closed, which is why the calendar timeline is 53 days rather than the sum of sequential phases.

Team

Delivery team

• Lyudmila Travkina — lead developer across the build and fix-and-feedback tail
• Nikita Tumasevic — QA iterations, fixes, and backlog resolution
• 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