27-Page Dental Template Customisation — 69 Days, 55h, Shipped
A 27-page dental template customisation delivered in 69 days on Kinsta. 92 reusable templates, 471 tracked QA issues, 85 checklist items signed off.
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): Johns Creek Dental Associates — a dental practice in Johns Creek, GA
Engagement: White-label template customisation for a US marketing agency
Delivered: November 2025 – February 2026 · ~69 days · ~55 hours across template customisation, content population, and a 471-issue QA backlog
The Craft of Template Customisation
27 pages of the agency’s Glowing dental template, customised for a Johns Creek practice — scope confirmed mid-build, when the agency expanded the brief to the full sitemap (issue #2000) and added a 20+ page legacy-content migration on top (issue #2024). Both bursts arrived after the initial sprint was underway; each was scoped as a discrete follow-up ticket with its own QA stream, keeping the core template launch on track while Korean-readiness infrastructure was coordinated in parallel.
Snapshot
| End-client industry | Healthcare — Dental |
| Engagement | White-label template customisation for a US marketing agency specialising in local-business websites |
| Project Type | Template Customisation |
| Scope | 27 customised pages + 20+ legacy-page migration on a Kinsta-hosted WordPress site |
| Timeline | 25 Nov 2025 – 02 Feb 2026 (~69 days) |
| Effort | 55.42 hours estimated · 28.0 hours logged (QA iterations often show 0.0 spent hours) |
| Team | 4 — Anton Hersun (project lead), Pavel Sazhin, Timur Arbaev, Natalia Bogatel |
| Templates | 92 reusable templates in the agency library, applied across 27 customised pages |
| Tech Stack | WordPress · Kinsta · Elementor · Gravity Forms · GTranslate · Weave SMS · Site Checker (xaverPRO QA plugin) |
| QA discipline | 471 tracked issues reconciled (235 SEO + 236 CX) across an 85-item launch checklist |
| Delivered | Live on Kinsta; awaiting final client content (Korean translations pending) |
| Engagement cadence | 3 agency-raised issues · 2 of 3 closed by handoff |
| Review rounds | ≈5 review rounds across the 69-day calendar window |
| Per-ticket effort | 119 internal Redmine tickets · median 6m / P75 26m per ticket |
| Launch checklist | 84 items, signed off before cutover |
The Brief
The agency brief was a Figma design package mapped to their existing dental template library, hosted on Kinsta, with English–Korean bilingual readiness. A US-based dental practice in Johns Creek, Georgia, needed the full template customisation treatment: every colour, photo, and line of copy swapped to match the agency’s design system, while the underlying template components remained untouched.
The initial scope covered a subset of the sitemap — the budget was recalculated when the agency confirmed 27 customised pages plus 20+ legacy pages, neither figure in the original estimate.
Risk context. The risk the agency was hedging against was scope expansion destabilising a template customisation already in motion. Two unplanned bursts arrived after the initial sprint was underway — a 27-page creation wave and a 20+ page legacy-content migration — neither covered by the original estimate. The danger was not merely hours overflow; it was that rushed customisation would leak into shared template components and degrade every other dental site that template served. Mitigation meant scoping each burst as a discrete follow-up ticket with its own QA stream, keeping the core template launch on track.
How We Did It
-
Figma-as-contract, template-as-canvas
The agency supplied per-page Figma frames and a 98-row sitemap. We treated the Figma file as the contract and the template as the canvas: every deviation from template defaults was documented against its corresponding Figma frame, so the “why” of each change was recoverable during QA and fix rounds. -
QA cycle at template-customisation scale
Template customisation generates more QA surface than a ground-up build — every template default that differs from the Figma design is a potential issue. The agency’s workbook tracked 235 SEO issues and 236 CX issues across an 85-item launch checklist. Our fix loop processed these in parallel with development, not as a post-build gate. Running QA concurrently with development rather than sequentially kept issue resolution inside the same context window as the customisation work. -
Customisation without drift
All client-specific changes lived in per-client overrides. The agency’s shared template components — headers, footers, global styles — were never modified. This kept the template library clean for the agency’s other dental clients and made rollbacks predictable. -
Cross-device verification
Multi-resolution screenshot capture ran across desktop, tablet, and mobile viewports. Layout shifts caused by custom image aspect ratios or bilingual toggle placement were caught before handoff.
Two scope bursts arrived mid-build — issue #2000 (27-page creation wave) and issue #2024 (migration of more than 20 legacy pages) — after the initial sprint was underway. Each was scoped as a discrete follow-up ticket with its own QA stream rather than absorbed silently into the open build. That sequencing kept the core template launch on track without leaking client-specific changes into the shared template components.
Results
| Outcome | Detail |
|---|---|
| URLs delivered | 27 customised pages live on Kinsta + 20+ legacy pages migrated |
| Templates applied | 92 template definitions in the agency library; subset applied per sitemap mapping |
| Launch checklist | 85 items signed off across design, functionality, content, SEO, and responsive categories |
| QA / SEO issues tracked + resolved | 471 tracked issues reconciled (235 SEO + 236 CX backlog rows) |
| Timeline | ~69 days (Nov 2025 – Feb 2026) |
| Effort | 55.42 hours estimated; delivered on budget |
| Team | Anton Hersun (project lead), Pavel Sazhin, Timur Arbaev, Natalia Bogatel |
| Hosting handoff | Kinsta staging → live; agency-managed DNS cutover |
Operational Integrity at handoff
The pre-handoff Site Checker pass on the 27-page dental build caught findings across three categories: a missing H1 on the homepage (Welcome to Johns Creek Dental Associates), the RankMath site-name field carrying the wrong value, and a nested service page (/dental-implants/full-mouth-implants/) silently redirecting to its parent — all three closed 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.
Process
| Phase | What happens | Duration |
|---|---|---|
| 1. Brief & estimation | Figma review, template mapping, hour estimate agreed | ~3 days |
| 2. Customisation development | Per-page Figma-to-template implementation | ~30 days |
| 3. QA iterations concurrent | Site Checker pre-handoff + agency issue-backlog reconciliation | ~25 days |
| 4. Fix rounds | Issue backlog triage, template-drift audit, regression checks | ~8 days |
| 5. Delivery | Kinsta handoff, agency sign-off, live cutover | ~3 days |
Phases 2 and 3 ran concurrently — QA issues were surfaced and fixed while customisation was still in progress, not after development was complete.
Team
- Anton Hersun — project lead, estimation, and agency coordination
- Pavel Sazhin — template customisation and Figma-to-Elementor implementation
- Timur Arbaev — QA iterations, fix rounds, and cross-device verification
- Natalia Bogatel — content integration and checklist sign-off support
The agency stayed the visible vendor throughout; all client-facing communication, design ownership, and hosting administration remained upstream of the customisation work.
For agencies with a branded template system
On a shared dental template, every client-layer override carries a structural risk. It can silently degrade the template for every other practice that runs it. For this practice it is a single-location upgrade; for others it is a multi-site dental group where one customisation will break every branded sibling. Child-theme overrides will break on the next template update, field schema will drift, and hardcoded brand fallbacks will stop propagating.
The question to ask a dev partner before committing is not “can you level up a dental template?” It is “how exactly will you isolate client-layer customisations so this practice’s brand logic survives the next template update?”
Send us the template source or template ID and your brand spec. We will audit your customisations against the shared template, flag the overrides that will break on the next update, and structure the work as discrete, isolated bursts. We return a fixed-hours quote. Free review, fixed quote in hours.
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.