32-Page Airway Dental Template Customisation

Client (end user): The Holistic Airway Dentist — a US dental practice specialising in airway-focused orthodontics
Engagement: White-label template customisation for a US marketing agency
Delivered: December 2025 · 55 days · 17 hours · 32 active URLs · on schedule

The Craft of Template Customisation

32 pages of an airway-focused orthodontics practice customised to a Figma spec on the agency’s Luminous template — 12 templates, 17 hours, 55 days. Midway through the build the agency restructured the URL architecture from /services/service-name/ to flat /<service-name>/ slugs for SEO; every internal link, menu item, and service-lander tile across the 32-page site had to be re-verified before handoff.

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 compact template customisation — 32 pages in 17 hours — where the density of page-hygiene decisions and a mid-build URL restructure made the QA loop the critical delivery mechanism.

Snapshot

The Brief

A US marketing agency delivered us a Figma design for The Holistic Airway Dentist and a deployment target on their branded Kinsta-hosted template system. The agency had already done the upstream work: design audit, client approval, hosting setup, content plan. What they needed was a development team that would map the Figma onto the template faithfully, through however many customisation iterations the design required.

The ask was operational. Take the Figma as the source of truth. Customise the template to match it page by page, breakpoint by breakpoint. Raise QA findings back to the agency in the shared workspace; don’t close them without agency sign-off.

What the agency needed to guard against was a dev shop that would treat a compact 17-hour engagement as a “quick homepage fix.” The initial brief was a single homepage modification, but the sitemap revealed 32 URLs — including 13 orthodontic and airway service pages, 8 insurance sub-pages, and a smile gallery. On a templated build, even a small scope multiplies quickly: every service page reuses the same template but requires its own Figma-matched copy, imagery, and CTA. A team that stops at the homepage leaves the agency with a half-customised site where template defaults leak into patient-facing pages. The 46 tasks tracked on this project — most of them page-level hygiene and QA — are the record of the discipline required to prevent that.

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. QA cycle at template-customisation scale. A clean template customisation is not “build once, review once”. It is “build, QA, adjust, QA, adjust”. The agency’s feedback system generated 12 concurrent tickets on a single review pass — each one a page-specific issue: draft links on insurance pages, duplicate smile galleries, placeholder blog landers, default-template pages that needed hiding, and FAQ sections that had to be stripped. Each ticket was resolved and returned for agency confirmation before the next pass. This volume is not a sign of instability; it is the discipline that separates a templated site that looks “roughly right” from one that matches the design.

3. Customisation without drift. Over the course of the project, every change we made to the branded template — whether to a page layout, a section component, or a style token — was documented against the Figma reference. No customisation “leaked” into the template’s shared components, which means this project’s work did not degrade the template for the next site it would serve.

4. 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 design deltas, not the whole site, which is how a templated build stays efficient without losing coverage.

The mid-build slug change — /services/ paths flattened to bare slugs after internal links were already wired — was the constraint that ordered the final QA pass. Resolving it required a cross-site sweep: every menu item, service-lander tile, and internal cross-link verified against the new URL structure before any page left staging. Six pages remained held back until that sweep cleared.

Operational Integrity at handoff

Pre-handoff QA surfaced draft links across the insurance sub-pages — the agency’s review flagged the Humana page and directed a sweep of all 8 insurance pages — alongside template-default FAQ sections leaking onto three pages and duplicate scaffold pages requiring holdback, all on top of the URL-restructure link sweep triggered mid-build when /services/ paths were flattened to bare slugs. 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 32 active pages and 12 templates, over 55 calendar days, inside the 17-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)
• Pavel Sazhin — QA iterations and fixes
• Timur Arbaev — developer support and QA
• Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)

Agency-side project management, design, and client communication remained with the partner agency throughout. Our team was invisible to the end client. All customisation requests came through the agency’s shared issue backlog; nothing about the build was visible to the end client directly. Each QA round was closed only after the agency-side reviewer confirmed the delta was resolved.

For agencies with a branded template system