Dental Template Customisation — 39 Days, 40h, Staged Release in Joplin MO

The Craft of Template Customisation

19 pages from an 84-URL dental sitemap customised against the agency’s “Glowing” template on Kinsta, with a Figma-specified Adobe Typekit font (EB Garamond) that had no integration in the brief — resolved in the first week before any page customisation began. The remaining 65 URLs on the sitemap stay buildable on the same foundations because every change in the pre-release set lives inside the per-client override layer, with no modifications to the agency’s shared template components.

Snapshot

The Brief

A US marketing agency handed us a Figma design for Northside Family Dentistry — a single-doctor general practice in Joplin, Missouri — together with deployment rights on their branded Kinsta-hosted dental template. The agency had already completed the upstream work: client discovery, design sign-off, content plan, hosting configuration, and a 84-URL sitemap that mapped the practice’s full intended web presence. What the agency needed from us was the customisation work to get the pre-release set live while respecting the structure of a site that was deliberately built for expansion.

The ask had two parts. First: take the agency’s Figma and the “Glowing” dental template and reconcile the two, page by page, for the subset of pages the agency and client had marked for the initial release. Second: do it without contaminating the template in a way that would create rework when the remaining 65 pages were added later. The pre-release set is not a simpler project than a full build — it is a full build’s discipline applied to a smaller footprint, with the added constraint that everything left out of scope has to remain buildable on the same foundations.

What the agency was hedging against was a dev shop that treats a partial scope as an invitation to take shortcuts. A dental template in active use across multiple practices carries shared components — headers, footers, navigation patterns, button styles — that power every site it serves. A dev team that modifies shared components to satisfy one project’s Figma deviation poisons those components for every other practice running on the same template. On a staged build, the risk compounds: shortcuts that look invisible in the pre-release set will surface as merge conflicts and design regressions when phase two begins. What the agency hired for was scope-respecting customisation — per-client overrides, Figma-matched, zero component bleed.

How We Did It

1. Figma-as-contract, template-as-canvas. The Figma file was the design specification. The “Glowing” dental template was the page framework. For each page in the pre-release scope, we compared the Figma against the template’s default output and customised only where they diverged — keeping every change inside the per-client override layer and nothing in the shared template. No design decisions originated on our side. Where the Figma specified layout elements not directly supported by the template’s existing component set — such as custom hero section structures — we chose clean Elementor markup over template-based or ACF-field approaches, so the customisation remained inside the per-client override layer without altering the agency’s shared template patterns.

2. Font and asset resolution up front. The Figma design used a licensed Adobe Typekit font (EB Garamond) that was not bundled in the template’s default setup. Before customisation began, we resolved the font embed — requesting the Typekit CSS snippet from the agency and confirming the full font weight range the design required was accessible. Starting customisation before the font was confirmed would have pushed a visual discrepancy through every subsequent QA round. Resolving it in the first days compressed the iteration loop.

3. 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 45+ individual QA findings in the shared backlog — granular issues ranging from linked buttons and layout alignment to meta-title accuracy and mobile responsiveness — each one a discrete item that required a fix, a return to staging, and a fresh agency sign-off before it closed. Behind those 45 items were 40 QA iteration sub-tasks tracked in Redmine. The volume is the record of precision, not instability.

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.

4. Customisation without drift. We contained every deviation from the template default — page layouts, section components, style tokens, font embeds, button variants — inside the per-client override layer. We did not modify the agency’s shared “Glowing” template components. The pre-release site and the phase-two expansion pages will share the same template foundations because no shortcut in phase one compromised them.

5. Cross-device verification. We QA’d customisations on desktop, tablet, and mobile viewports. We caught and resolved mobile-specific issues — including a button layout regression on narrow screens that required a targeted CSS fix — during the QA loop before handoff. Each QA round covered the pages affected by that round’s deltas, not the full site, which is how a staged build stays efficient without losing coverage.

The font had to be confirmed first. The Adobe Typekit embed was missing from both the Figma and the brief — resolving it in the first days meant every subsequent QA round was reviewing the actual design, not a visual stand-in. With the foundation confirmed, 40 QA rounds across 39 days closed each delta cleanly against the “Glowing” template’s override layer without touching shared components.

Operational Integrity at handoff

We built hero sections without ACF template fields — we made the call in the first development days to keep per-client overrides isolated from the agency’s shared “Glowing” template components. We caught and resolved a mobile button regression on narrow screens in the final QA round before handoff. Pre-handoff QA ran through Site Checker — see our QA approach for the categories and the rule that nothing ships with an open finding. After we handed off, the agency ran its own QA and we resolved each item it raised before sign-off.

Customisations stayed in the per-client overrides. We did not modify the agency’s shared template components.

Results

In short: we implemented the agency’s Figma against the “Glowing” dental template for the pre-release page set, over 39 calendar days, inside the 40-hour estimate — with the 65-page phase-two expansion still buildable from the same clean foundations.

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

• Natalia Bogatel — lead developer (template customisation and Figma-to-layout mapping)
• Timur Arbaev — QA and developer support across customisation rounds
• Pavel Sazhin — QA iterations and project communication
• Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)

The agency managed the end-client relationship, the Figma design, the content plan, and the hosting environment. The practice in Joplin knew the agency as its web partner and never had reason to learn who customised the templates — requests arrived through the shared backlog, and each iteration closed only when the agency-side reviewer confirmed the fix was resolved to spec.

For agencies with a branded template system