35-Page Dental Template Customisation
35-page dental template customisation across 9 agency templates — 60 hours, 127 days. 12 pages built to Figma; 54+ QA items closed across 88 issues.
Screenshots captured by automated tooling — some elements may not have loaded fully or may layer on top of each other. For the most accurate view, visit the live site →
Rebuild the site on a new stack. Implement the spec. Don't improvise. Hand it back ready for cutover.
Client (end user): Revive Dentures and Implants — Dr. Robert Long, Durham, NC
Engagement: White-label dental template customisation for a US marketing agency
Delivered: February 2026 · 127 days · 60 hours · 35 URLs mapped, 12 built to Figma in QA · on schedule
The Craft of Template Customisation
35 pages across a deep implant-and-dentures taxonomy — full-arch, single, multiple, dentures, bone grafts, sinus lifts, extractions — mapped to the Sparkling template against a Figma spec that did not cover all 35. Mid-project the agency requested a full ACF de-scaffolding, and four sub-service pages (All-on-4, All-on-X, hybrid dentures, same-day implants) were added with purpose-written content. We built 12 pages to Figma; 23 stayed in draft until client assets arrived.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — Dental (Prosthodontics & Implant Dentistry) |
| End-client | Revive Dentures and Implants (Dr. Robert Long, Durham, NC) |
| Engagement | White-label template customisation for a US marketing agency specialising in local-business websites |
| Project Type | WordPress template customisation (agency’s branded template + per-page Figma design on Kinsta) |
| Scope | 35 URLs mapped — 12 built to Figma and in QA at handoff, 23 held back pending client content or scaffolded with template defaults |
| Timeline | 127 days (29 Sep 2025 – 2 Feb 2026), on schedule |
| Effort | 60 hours estimated — development, QA iterations, and project management |
| Team | 4 specialists |
| Templates | 11 reusable templates in the agency library, 9 applied across the 35 mapped pages |
| Tech Stack | WordPress · Elementor · Kinsta hosting · Figma-driven per-page design · Gravity Forms · Site Checker (xaverPRO QA plugin) |
| QA discipline | 54+ tracked SEO issues reconciled in the agency’s backlog across a 40-item launch checklist (CX tab lightly populated for this project) |
| Engagement cadence | 3 agency-raised issues · all closed by handoff |
| Review rounds | ≈8 review rounds across the 127-day calendar window |
| Per-ticket effort | 88 internal Redmine tickets · median 10m / P75 28m per ticket |
| Launch checklist | 39 items, signed off before cutover |
The Brief
A US marketing agency delivered us a Figma design for Revive Dentures and Implants — a prosthodontic practice in Durham, NC, offering full-arch implants, single and multiple implants, dentures, bone grafting, and IV sedation — 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.
Risk context. A prosthodontic practice’s site lives or dies on visual credibility — patients evaluating full-arch implant restoration notice font-weight mismatches and hero-image cropping the same way they notice a sloppy waiting room. The risk the agency was hedging against was not just incomplete content (23 of 35 mapped pages lacked client assets at launch); it was the drift between the Figma design and the template defaults that would show through on every page where the design spec and the content doc did not fully overlap. Customising a dental template for implant-and-denture services means reconciling deep service taxonomies — All-on-4, All-on-X, hybrid dentures, sinus lifts — against a template built for general dentistry, without letting the template’s defaults dictate the patient journey.
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 54+ 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.
Working under a mid-project de-scaffolding request — the agency asked for all ACF templates to be replaced with native Elementor pages before handoff — meant every page built against the original spec had to be rebuilt from its underlying structure. That constraint, absorbed inside the 127-day window without a timeline extension, is what kept the 60-hour estimate intact.
Operational Integrity at handoff
Pre-handoff QA on the Figma-to-template mapping caught two concrete drift points: a font-weight mismatch where Figma specified 700 but browser rendering ran heavier than the design (adjusted to 600 across all headings), and Elementor widget-scoped CSS that silently dropped during the adaptive review — both resolved before the build reached the agency. 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
| Metric | Outcome |
|---|---|
| URLs delivered | 35 mapped — 12 built to Figma and in QA at handoff, 23 held back pending client content or scaffolded with template defaults |
| Templates applied | 9 of 11 reusable templates built and mapped across the 35 pages |
| Launch checklist | 40 items signed off |
| QA / SEO issues tracked + resolved | 54+ items reconciled across the agency’s SEO issue-backlog tab (CX tab lightly populated for this project) |
| Redmine QA iterations | 20+ of 88 tasks tracked at the iteration level |
| Timeline | 127 days, delivered on schedule |
| Effort | 60 hours against a 60-hour estimate — no overrun, no scope creep |
| Team | 4 specialists |
| Hosting handoff | Live on the agency’s Kinsta template environment |
| Page health at handoff | 12 / 35 pages with full content in QA; remainder scaffolded or held back |
The outcome, restated plainly: the agency’s Figma was implemented against their branded template across 35 mapped pages and 9 templates, over 127 calendar days, inside the 60-hour estimate.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | ~3 days | Figma reviewed, template access confirmed, scope agreed |
| Customisation development | ~4 weeks | Page-by-page template customisation to match Figma |
| QA iterations (concurrent) | ~12 weeks | 20+ QA rounds logged; each closed only on agency sign-off |
| Fix rounds | ~2 weeks | Post-review corrections, content holdbacks, visual refinements |
| Delivery | final day | Site live on Kinsta |
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)
- Pavel Sazhin — QA iterations and fixes
- 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
If you have been caught mid-project when a client site needed its ACF scaffolding removed after initial build — because the agency needed clean Elementor pages, not template overrides — that is a scope shift most dev partners handle badly. Send us a current project brief or template spec and describe the constraint; we will return a fixed-hours estimate that accounts for the de-scaffolding pass, not just the initial build. No cost, no obligation.
Don't have a spec yet? Send a one-paragraph description — we'll come back with the questions worth asking. Send a description →
Site Checker runs before the agency sees anything.
Before handoff, every staging build runs through Site Checker — the WordPress QA plugin we built and maintain. It is a fail-zero gate: nothing goes to the agency with an open failure. Warnings are reviewed and judged non-blocking; the agency gets a clean slate to run their own QA layer against, not a staging site with known issues in the queue.