26-Page Dental Template Customisation in 59 Days — White-Label for a US Marketing Agency

The Craft of Template Customisation

26 pages of a dental practice template customisation across 10 Luminous-template page types — 13 service pages across cosmetic and family care tracks, two doctor bios, smile gallery, and supporting pages — all built to a per-page Figma spec on WP Engine. The agency sourced content per page from the practice’s live site and newly prepared material; our job was holding the Figma layout on both service tracks without letting content-sourcing decisions drift the structure.

Done right, this approach buys you both speed and a consistent result — but that only holds when the customisation stays disciplined. Hand it to a team that reads its own intent into the Figma, trims the QA rounds, or wanders off the template’s design system, and you would have been better off building from nothing.

Snapshot

The Brief

A US marketing agency delivered a Figma design for SmilePro Dental and access to their branded WP Engine template system. The agency had sourced the sitemap from their SEO team, worked with the client to define a fresh design direction using the Luminous template, and built content documentation per page. Our task was to take that Figma as the authoritative design spec and customise the template to match it — across a 26-page build where some pages had content pulled from the existing live site and others were designed with entirely new content from the ground up.

The agency’s ask was focused on clean execution. Apply the template to each page’s Figma frame precisely, flag any content gaps rather than bridging them with guesswork, and sustain the fix loop until every backlog item was reconciled.

The agency’s content documentation did not always align with the Figma block structure — a section designed as a map-and-contact block was delivered with long-form copy under different headings, and some content blocks appearing on staging had no equivalent in the template or the Figma file. Each such gap had to be flagged and resolved through the agency’s shared backlog rather than interpreted on our side.

What the agency was guarding against was a content-sourcing problem that can silently degrade a template build’s consistency. SmilePro Dental had an active site with content organised around its original navigation structure — cosmetic care, family care, and dental services. The new Figma reorganised that content across the agency’s template system with new page structures and a different visual hierarchy. A dev team that migrates content from the old site into new template blocks without checking against the Figma risks embedding structural mismatches that only surface in QA. On a build where the end client had indicated specific imagery from their own archive and had an existing patient gallery, mapping each content block to its source was not a preliminary task — it ran in parallel with the customisation through every fix round.

How We Did It

1. Figma-as-contract, template-as-canvas. The Figma carried the binding design; the branded template supplied the structural bones underneath each page. We worked page by page to bring the two into agreement — leaving the template’s default layout in place wherever it already matched the Figma, and customising only where the Figma asked for something different. None of those design calls started with us.

2. Content-source mapping before building. SmilePro Dental’s service pages fell into two categories: pages with content coming from the agency’s structured per-page documents, and pages where the source was the practice’s existing live site. Before building, we confirmed the content lineage for each page — reviewing existing page content against the Figma block structure for fit, and flagging gaps to the agency rather than silently filling them from the template’s default copy. The cosmetic-versus-family-care split in the practice’s service taxonomy drove this: a content block that worked on a cosmetic care service page (veneers, implants, whitening) would not carry the right framing to a family care page (crowns, bridges, endodontic care) if lifted without review.

3. QA cycle across cosmetic and family tracks. The agency’s shared issue backlog accumulated 78+ items across SEO and CX categories, reconciled against a 29-item launch checklist. Post-handoff agency QA flagged meta, imagery, and content-block issues across both service tracks; a round stayed open until the agency’s reviewer had personally confirmed the fix held. The two-track service structure meant that a fix applied to one cosmetic care page needed to be checked for consistency across all pages in that track — a regression that is easy to miss when a build has 13 service pages of two distinct flavours.

4. Customisation without drift. Whatever we touched on the branded template — a layout, a section component, a style token — went into the per-client override layer and nowhere else; the agency’s shared Luminous template stayed exactly as we found it. That distinction earns its keep on a WP Engine multi-tenant setup where other practices sit on the same base: nothing from SmilePro Dental’s two-track service work bled into the components those other sites depend on.

5. Cross-device verification. We checked the customisations in Chrome, Firefox, Safari, and Edge at desktop, tablet, and mobile sizes — the breakpoint set the agency works to. A round only ever touched the pages its own deltas had changed, so the cycles stayed short even while the agency backlog chewed through its full list.

The recurring tension in this engagement was content that arrived structured differently from the Figma — a map-and-contact block where the agency’s documents sent long-form copy, a FAQ section that had to be stripped mid-build. Flagging each gap to the shared backlog rather than interpreting it on our side was what kept the cosmetic and family tracks consistent with each other through five QA rounds.

Operational Integrity at handoff

The map-and-contact block held long-form copy where the Figma showed a CTA — built to the agency’s own content documents, so the mismatch surfaced at first QA pass. The SEO QA task also flagged a duplicate-URL ambiguity on row 9 that needed agency clarification before we could close it. Before handoff the build went through Site Checker — how we run QA sets out the categories and why an open flag keeps a page from shipping. Once it was in the agency’s hands, they vetted it their own way and routed findings into the shared backlog, feeding our fix loop to sign-off.

Every customisation lived inside the per-client overrides. Shared template components stayed untouched.

Results

Net of it all: the agency’s Figma went onto their branded template across 26 pages and 10 templates, the calendar ran to 59 days, and the work stayed under the 69-hour estimate.

Process

Build and QA overlapped throughout, which is normal for template-customisation work: there is no tidy “QA phase” to close out, just a loop that keeps turning until the agency calls it done.

Team

Delivery team

• Nikita Tumasevic — lead developer (template customisation and Figma-to-layout mapping)
• Pavel Sazhin — QA lead (backlog review, agency coordination)
• Anna Polunina — template customisation support and QA
• Evgeniy Karpov — developer (SEO QA resolution, post-handoff CX fixes)
• Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)

SmilePro Dental knew only the agency. Every customisation request reached us through the agency’s shared backlog, never from the practice, and each fix round shipped under the agency’s name once their reviewer confirmed it was resolved to spec.

For agencies with a branded template system