54-Page Dental Template Customisation

Client (end user): Dentaire Dental — a full-spectrum dental practice in Austin, Texas
Engagement: White-label template customisation for a US marketing agency
Delivered: November 2025 · 84 days · 70 hours · 54 URLs · on schedule

The Craft of Template Customisation

54 pages of a full-spectrum Austin dental practice customised from the agency’s dental-template6 against a Figma covering 10 page templates — services lander, 39 service pages across seven sub-specialties, doctor bio, patient resources, and contact. The client had supplied content written for the original template layout rather than the Figma, so each page required reconciling what the design asked against what the copy assumed — a discipline that ran through all 39 service pages uniformly.

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.

This case study is a record of a template customisation executed to the agency’s Figma across a full-spectrum dental site, where the breadth of the service taxonomy was the central challenge to disciplined delivery.

Snapshot

The Brief

A US marketing agency delivered a Figma design for Dentaire Dental and access to their branded Kinsta template system. The agency had handled the upstream preparation: client-approved design, hosting configuration, and a Google Sheets sitemap with per-page template assignments and content references. Our task was to take that Figma as the single source of truth, map it onto the template page by page, and sustain the review cycle for as long as it took to reach sign-off.

The ask was operationally precise. Customise every deviation from the template default to match the Figma exactly — across 10 templates applied 54 times, with no design decisions originating on our side.

The specific risk the agency was managing against was scale-and-breadth creep. Dentaire Dental is not a single-focus dental office; it covers family dentistry, preventive care, cosmetic treatments, restorative procedures, orthodontics, oral surgery, specialty services, dental technology, and emergency care — 39 service pages organised across 7 sub-specialty subtrees under one services lander. On a site with that many thematically grouped service pages, each using the same Service Page template but requiring unique content mapping, a team that applies template-level variations inconsistently creates a fragmented result where one sub-specialty’s pages look polished and another’s look like placeholders. The agency hired for the discipline to apply the same customisation standard across all 39 pages uniformly, from the narrowest service page to the broadest sub-specialty lander.

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. Sub-specialty taxonomy mapped, not assumed. Dentaire Dental’s 39 service pages are not a flat list — they form a seven-branch taxonomy (Family, Preventive, Cosmetic, Restorative, Orthodontic, Oral Surgery, Specialty, Emergency, Technology). The sitemap defined the structure; our job was to ensure each Service Page template application was consistent within its branch, so that moving from one sub-specialty to another felt continuous rather than patchwork. Each page’s H1, meta structure, and content block layout was mapped from the agency’s Figma and content references — not interpreted. When the provided content didn’t align with Figma block structure, the gap was flagged for agency resolution rather than bridged with a best guess.

3. QA cycle at multi-specialty scale. Of the 40 tasks tracked in Redmine, 24 carried the QA label — individual rounds where the agency flagged design deltas or client-requested changes, we fixed, and returned for review. Beyond Redmine, the agency’s shared issue backlog accumulated 142+ SEO findings across an 83-item launch checklist, plus a separate feedback-comment layer with 67 items submitted directly by the end client through a visual annotation tool. Each channel fed the same fix loop; nothing was left to stack up unaddressed. The dual-channel structure — structured Redmine issues managed by the agency plus free-form visual annotations submitted directly by the end client — meant the team had to reconcile two feedback sources whose priorities sometimes diverged, with items outside the original Figma scope deferred to the agency’s post-launch backlog rather than addressed mid-build.

4. Customisation without drift. Every change we made to the branded template — page layout, section component, or style token — was contained within the per-client override scope. The Service Page template applied 39 times remained consistent across the whole site because no customisation “patched” the shared component rather than the per-page layer. A template handling 39 service pages across seven sub-specialties has more surface area where per-page overrides can silently drift into shared template logic; keeping the boundary clean on every iteration was the discipline the agency was buying.

5. Cross-device verification. Customisations were QA’d against Chrome, Firefox, Safari, and Edge on desktop, tablet, and mobile viewports — the standard agency breakpoint set. Each QA round covered the pages affected by that round’s deltas rather than re-auditing the full 54-page set, which is how a large templated build stays efficient without losing coverage.

The client had supplied copy written for the original template rather than the Figma, so every page that hit this gap required a decision: flag it and hold for agency resolution, or bridge it with a best guess. We flagged every one. That discipline — gap-flagging rather than interpreting — is what kept the 39 service pages consistent across all seven sub-specialty branches without editorial drift accumulating silently across the build.

Operational Integrity at handoff

QA on this build caught two categories of issue before handoff: client-supplied copy had been written against the original template rather than the Figma — mismatches across the 54 pages flagged and reconciled before the agency’s review — and og:locale was set to GB instead of US, caught in the SEO checklist and corrected pre-handoff. 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.

Customisations stayed in the per-client overrides; the agency’s shared template components were not modified.

Results

The outcome, restated plainly: the agency’s Figma was implemented against their branded template across 54 pages and 10 templates, over 84 calendar days, inside the 70-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 (initial template customisation and Figma-to-layout mapping)
• Pavel Sazhin — QA lead (iteration rounds, agency backlog review, sign-off coordination)
• Anna Polunina — template customisation support and QA
• Timur Arbaev — developer support on later customisation rounds
• Lyudmila Travkina — developer (primary build execution across all 54 pages and multi-specialty branches)
• Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)

All customisation requests from the end client reached us through the agency’s shared review system. Our team’s identity was not visible to Dentaire Dental. Each QA round was released only after the agency-side reviewer confirmed the changes were resolved to spec.

For agencies with a branded template system