24-Page Dental Template Customisation

Client (end user): Church Family Dentistry and Cosmetics — Dr. Will Church, Durham, NC
Engagement: White-label template customisation for a US marketing agency
Delivered: December 2025 · 78 days · 67 hours · 24 URLs mapped, 19 live at handoff · on schedule

The Craft of Template Customisation

24 pages of a Church Family Dentistry build mapped to the agency Figma on the Luminous template — 19 shipped at handoff, 5 held back because the client had not delivered images or policy text. The agency owned the Figma spec and the content deadlines; we owned the per-page reconciliation across six QA rounds, catching a broken sitemap, a base64-encoded hero image, and heading-level jumps flagged by Site Checker before the build left staging.

Snapshot

The Brief

A US marketing agency delivered us a Figma design for Church Family Dentistry and Cosmetics 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 modify shared template components to hit a deadline — a shortcut that looks invisible until the agency discovers the same “fix” has degraded a different client’s site that rides the same template. A dental template in active use serves multiple practices at once; one project’s customisation cannot leak into the shared layer. That is the discipline the agency hired for, and it is what the 20 QA iterations on this project were built to verify.

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”. Over the course of this project, we tracked 20 QA iterations in Redmine and reconciled 76+ line items in the agency’s shared issue-backlog workspace — individual rounds where the agency flagged design deltas, missing images, and content inaccuracies, we reviewed, fixed, and returned the build for another review. 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.

The principle behind this is simple: on a templated build, the QA loop is where the value is delivered. A shorter QA cycle is a weaker match to the design, not a faster delivery.

3. Customisation without drift. 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. Each QA round covered the pages affected by the round’s design deltas, not the whole site — which is how a templated build stays efficient without losing coverage.

The QA cycle was what made the Figma match achievable. Twenty iterations, 76+ tracked items, and the pre-handoff pass that caught a base64-encoded hero image buried in template code and a fully broken sitemap — none of that surfaces without a discipline of building, reviewing, fixing, and returning until the agency’s reviewer signs off.

Operational Integrity at handoff

Pre-handoff QA on this build caught a rogue /local/ URL that Rank Math SEO PRO had silently added to the sitemap (auto-installed, not part of the brief), and flagged PNG icons that would not render crisp on high-DPI screens — both resolved before the agency saw the staging build. 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 24 mapped pages and 16 templates, over 78 calendar days, inside the 67-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

• Pavel Sazhin — QA iterations and fixes
• Anna Polunina — template customisation support and QA
• Evgeniy Karpov — lead developer (template customisation and Figma-to-layout mapping)
• Vladimir Kozlov — development support
• Timur Arbaev — QA iterations and developer support
• 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. Customisation requests came through the agency’s shared issue backlog; nothing about the build was visible to the end client. Each round was closed only when the agency-side reviewer signed off.

For agencies with a branded template system