25-Page Dental Template Customisation

Client (end user): Centergate Family Dentistry — a US dental practice
Engagement: White-label template customisation for a US marketing agency
Delivered: October 2025 · 103 days · 55 hours · 25 URLs · on schedule

The Craft of Template Customisation

25 pages across 10 Figma-linked templates on a Kinsta dental template — 12 of those pages using one Service Page template, each with its own content, imagery, and CTA. Mid-engagement, the agency’s QA layer caught paragraph-bolding inconsistency across all 12 service pages and duplicate meta descriptions on each; both required a systematic pass, not a page-by-page spot fix. That’s the discipline cost of applying one template twelve times: the fidelity verification runs twelve times too.

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, with a QA profile that shows the discipline it takes — on an engagement where the same Service Page template was applied twelve times, each with its own content, imagery, and layout variation.

Snapshot

The Brief

A US marketing agency delivered us a Figma design for Centergate Family Dentistry and a deployment target on their branded Kinsta-hosted template system. The agency had already done the upstream work: design audit, client requirements capture, hosting setup, and content sourcing via Google Docs per service page. What they needed was a development team to map the Figma onto the template faithfully and sustain the QA loop for as long as the agency’s review process required.

The ask was operationally precise: customise the template to match the Figma page by page, raise findings back into the shared backlog, and return every iteration only after the agency-side reviewer had confirmed the delta was resolved. The 25-page scope included twelve service pages — each with its own Figma frame, content block, and imagery — that all shared the same underlying Service Page template. Some Figma frames specified visual treatments the template could not replicate directly, requiring CSS workarounds such as backdrop-filter overlays where the template components had no equivalent.

What the agency needed to guard against here was template-repetition fatigue. When one template is applied twelve times across a single practice’s service ladder, the risk is not a dramatic break — it is cumulative drift. The third service page matches the Figma, but by the eighth the spacing has slipped, the CTA block has drifted, and the image aspect ratio has silently changed. A dev partner that treats repeated template use as “copy and adjust” rather than “customise and verify” leaves the agency with a site that looks correct in aggregate but fails on the details that patients notice. The 305-item issue backlog on this project is the record of that discipline applied page by page.

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 tracked 305 items across two issue-backlog tabs (186 SEO findings and 119 CX findings), of which 85 were marked Completed at the time of handoff. Each round was a page-specific or site-wide review where the agency flagged design deltas, we reviewed, fixed, and returned the build for another pass.

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 more efficient handoff.

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. Where effects such as translucent overlays fell outside the template’s native capability set, the team chose a CSS implementation over requesting a Figma revision — preserving the design intent without adding an agency-side approval cycle.

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.

Applying one Service Page template twelve times meant the fidelity check ran twelve times too. When the agency’s CX review caught paragraph-bolding drift across all twelve service pages, it required a systematic pass — not twelve individual fixes, but a single corrective sweep. That is what the constraint demands: the customisation work compounds with each repetition, and the verification load has to match it.

Operational Integrity at handoff

QA on this build carried the template-repetition load directly — the agency’s CX review caught paragraph-bolding drift across all 12 service pages, and the SEO tab caught an H-tag hierarchy error on the homepage; the 78-item pre-handoff checklist, including Trailing Slash Consistency and Status Codes, was signed off item by item before any page left staging. 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 25 pages and 10 templates, over 103 calendar days, inside the 55-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
• Anna Polunina — developer support on content and image rounds
• Evgeniy Karpov — development support
• Lyudmila Travkina — QA pass and pre-handoff review coordination
• Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)

The agency held the end-client relationship throughout. All customisation requests moved through the agency’s shared backlog; Centergate Family Dentistry did not interact with our team directly. Every iteration round was released only once the agency-side reviewer confirmed the changes were resolved to spec.

For agencies with a branded template system