22-Page Dental Template Customisation in 183 Days — White-Label for a US Marketing Agency

The Craft of Template Customisation

22 pages across 11 Figma-linked templates on a WP Engine dental template — initial build completed, agency QA signed off, site live. Then a category rename changed the slug from /service/ to /services/, and “many links to /service/ now became 404”. Fixing it on a live patient-facing site required three controlled QA rounds across December 2025 and January 2026: update slugs, verify navigation, footer, and in-page CTAs each time, then hold for agency sign-off before the next pass.

The value is speed with consistency — but only if the customisation is disciplined. A dev team that “interprets” the Figma, skips QA rounds, or deviates from the template’s design system is worse than starting from scratch.

Post-launch URL structure changes — coordinated after the initial handoff — required controlled re-engagement without disrupting the already-live site.

Snapshot

The Brief

A US marketing agency delivered a Figma design for Heart of Hingham Dental and access to their branded WP Engine template system. The agency had coordinated with the client on design direction, hosting configuration, and a Google Sheets sitemap specifying content and template assignments per page. Our task was to customise the template to match that Figma across 22 pages, using the agency’s content documentation as the content source, and to sustain the fix loop through the full sign-off process.

The ask was direct: implement the Figma, flag content gaps rather than improvise — the agency noted that many service pages lacked photography and would need placeholder images until the link-building team sourced proper shots — and return each fix round to the agency’s backlog until closed.

The engagement ran longer than its scope would suggest for a reason that was not a scope problem: after initial launch, the practice required a URL structure change that was coordinated post-handoff. A dental practice’s URLs are not just addresses; they are the nodes that internal navigation, the sitemap, and any already-indexed pages depend on. Changing them after launch requires a controlled sequence — new slugs on the live environment, navigation updated to the new paths, sitemap and redirect logic confirmed — without leaving orphaned links visible to patients. The URL structure change added three post-launch QA rounds across December 2025 and January 2026, each verified and closed before the engagement was fully signed off.

What the agency was hedging against by retaining us through the URL change was the silent-failure mode of live-site URL work: a slug change that updates the page but misses a navigation link, or a redirect that routes correctly in the header but fails in the footer or blog CTA. When a dental practice’s patients are booking appointments through links they have bookmarked or followed from local search, a broken navigation path on a live site is not a draft-environment problem.

How We Did It

1. Figma-as-contract, template-as-canvas. The Figma file was the design spec. The branded template was the underlying page structure. Our job was to reconcile the two page by page — where the template’s default layout matched the Figma, we kept it; where the Figma required a deviation, we customised. No design decisions originated on our side.

2. Placeholder discipline on content-incomplete pages. The agency’s sitemap indicated that the majority of service pages had AI-prepared content rather than imagery from the practice. Rather than leaving layout gaps visible in staging, each content-incomplete page received a standardised placeholder image from the template’s own asset library — a uniform approach that kept the staging review clean while the agency coordinated final image sourcing in parallel. Each placeholder was noted in the sitemap comments so the agency’s link-building team could prioritise replacements systematically.

3. QA cycle across an outsized issue backlog. Of the 30 Redmine tasks, 15 carried the QA label. Beyond Redmine, the agency’s shared issue backlog accumulated 189 SEO findings and 135 CX findings — 324+ items in total, reconciled across a 73-item launch checklist. That volume for a 22-page site reflects the end client’s engagement level: Heart of Hingham Dental submitted feedback directly through a visual annotation tool, and the agency ran a thorough post-handoff review cycle. Each backlog item was addressed and closed before sign-off; no category was partially reconciled and deferred.

4. Post-launch URL restructure, contained. The URL structure change — tracked across four Redmine tasks in December 2025 and January 2026 — required modifying page slugs on the live WP Engine environment, updating all internal navigation to match, and verifying the full site’s link map on each QA pass. The three post-launch QA rounds confirmed that the new URL structure was consistent across the homepage navigation, footer links, in-page CTAs, and blog cross-links before the final close.

5. Customisation without drift. We applied every change we made to the branded template — including the post-launch URL amendments — within the per-client override scope. We never modified the agency’s shared template components at any point in the engagement, including during the post-launch work.

6. Cross-device verification. Customisations and the post-launch URL changes were QA’d against Chrome, Firefox, Safari, and Edge on desktop, tablet, and mobile viewports throughout the engagement.

The post-launch URL restructure ran three QA rounds across December 2025 and January 2026 — each one verifying that the slug change from /service/ to /services/ had propagated to navigation, footer links, in-page CTAs, and blog cross-references on the live site before the engagement could close. We held post-launch maintenance to the same standard as the initial build: nothing shipped until the link map was clean.

Operational Integrity at handoff

The pre-handoff QA checklist for this engagement included a dedicated trailing-slash uniformity pass across all 22 URLs — and when a post-launch category rename changed /service/ to /services/, the slug change surfaced broken internal links across the site, which the URL-restructure QA rounds resolved before the engagement closed. Pre-handoff QA ran through Site Checker — see our QA approach for the categories and the requirement that every check pass before a page could ship. Once handed off, the agency checked the build its own way, and we worked the items it filed down to sign-off.

Customisations stayed in the per-client overrides. We did not modify the agency’s shared template components.

Results

Plainly put: we implemented the agency’s Figma against their branded template across 22 pages and 11 templates, sustained through a 324+ item QA backlog and a post-launch URL restructure, over 183 calendar days, inside the 69-hour estimate.

Process

Development and QA ran concurrently — this is characteristic of template-customisation work, where no “QA phase” closes cleanly. The loop runs continuously until the agency signs off.

Team

Delivery team

• Nikita Tumasevic — lead developer (template customisation and Figma-to-layout mapping, post-launch URL restructure)
• Pavel Sazhin — QA lead (backlog review, post-launch verification coordination)
• Anna Polunina — template customisation support and QA
• Timur Arbaev — developer support on mid-engagement customisation rounds
• Lyudmila Travkina — developer (service page build, content-placeholder implementation)
• Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, post-launch coordination)

Heart of Hingham Dental knew the agency, and only the agency — our name never reached the practice. Every request, the post-launch URL restructure included, was coordinated through the agency’s shared issue backlog and answered there. The practice booked patients on a site that read as the agency’s own work; the agency owned the account, and we did the building it depended on.

For agencies with a branded template system