37-Page Pediatric Dental Template Customisation
A 37-page pediatric dental template customisation, two-location, bilingual — 16 templates, 27 hours, 470+ SEO/CX items reconciled across 50 days.
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): Children’s Dentistry of Georgia — a pediatric dental practice in Chastain, GA, led by Dr. Todd Asarch
Engagement: White-label template customisation for a US marketing agency
Delivered: November–December 2025 · 50 days · 27 hours · 37 URLs · on schedule
The Craft of Template Customisation
37 URLs of a pediatric dental template customisation — homepage, five Chastain service pages, a bilingual Spanish-speaking variant, and four utility pages built to a text-only Figma spec — delivered across 16 agency templates in 27 hours. The agency owned the Figma; our job was to keep each reused Service Page template accurate across every location and language variant, and provision a text-only layout for the utility pages the existing template set did not cover.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — Pediatric Dentistry |
| End-client | Children’s Dentistry of Georgia (Chastain, GA) |
| Engagement | White-label template customisation for a US marketing agency specialising in local-business healthcare websites |
| Project Type | WordPress template customisation (agency’s branded template + per-page Figma design on Kinsta) |
| Scope | 37 URLs — homepage, services lander, 20+ service pages (pediatric dental, preventive, restorative, sedation, emergency, area-specific), about, doctor bio, contact, blog lander + post, payment and insurance pages, Spanish-speaking page, legal |
| Timeline | 50 days (10 Nov – 30 Dec 2025), on schedule |
| Effort | 27 hours — split across template development, QA iterations, fixes and project management |
| Team | 4 specialists |
| Templates | 16 reusable templates provided by the agency, all applied across the 37 pages |
| Tech Stack | WordPress · Elementor · Kinsta hosting · Figma-driven per-page design · Yoast SEO · Gravity Forms · Site Checker (xaverPRO QA plugin) |
| QA discipline | 235 + 236 rows in agency SEO + CX backlog tabs; 85-item launch checklist |
| Engagement cadence | 3 agency-raised issues · 2 of 3 closed by handoff |
| Review rounds | ≈4 review rounds across the 50-day calendar window |
| Per-ticket effort | 9 internal Redmine tickets · median 28m / P75 4.2h per ticket |
| Launch checklist | 84 items, signed off before cutover |
The Brief
A US marketing agency delivered us a Figma design for Children’s Dentistry of Georgia and a deployment target on their branded Kinsta-hosted template system. The agency had already done the upstream work: sitemap with per-page content docs, branding assets, contact and credential setup, and the client’s social profiles linked. Our job was to customise the template page by page against the Figma until the agency signed off on each round.
The practice is a solo-practitioner pediatric dental site — one doctor, no orthodontics ladder — but with a multi-location surface that is unusual for a compact build. The workbook sitemap maps pages for two primary locations (Chastain and Kennesaw), three area-specific service pages (Buckhead, Sandy Springs, North Buckhead), and a Spanish-speaking page. All of these reuse the same Service Page template. On a 27-hour engagement, the risk is not visual drift; it is content-language and location-identity leakage across reused template instances. A Chastain address string or an English CTA label propagating into the Spanish page is a silent failure that breakpoint QA alone will not catch. The agency hired us to prevent that. A further constraint was that several utility pages — payment methods, privacy policy, terms of service — required a layout the existing template set did not provide, and the workbook’s Content tab had empty body-copy rows for most pages, meaning content had to be sourced independently from the agency’s editorial workflow rather than from a single document.
Risk context. Twenty-plus pages sharing a single Service Page template — across two primary locations, three area-specific URLs, and a Spanish-speaking variant — turns the template’s reuse advantage into a leakage risk. A Chastain address string propagating into the Kennesaw page, or an English CTA label surviving into the Spanish page, is a silent failure: it passes visual breakpoint review, it passes link checks, and it only surfaces when a parent or patient reads the wrong content. On a 27-hour compact engagement, the discipline to track which elements are page-local versus template-global on every one of those reused instances is what separates a clean build from a content-accuracy liability.
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. For a pediatric site that has to read as warm and parent-trustable, that “no improvisation” rule kept every page honest.
2. Multi-location and bilingual discipline on a reused template. The Service Page template was applied across more than twenty pages — Chastain location pages, Kennesaw location pages, area-specific pages, and a Spanish-speaking page. Each needed its own location name, service context, and language register. Tracking which elements were page-local versus template-global was the underlying work in each customisation iteration. The agency’s workbook explicitly called for an additional text-only template for utility pages (payment methods, privacy policy, services, terms and conditions), which we provisioned without touching the shared template components. We chose a minimal text-only layout for those pages rather than adapting the Service Page template, because forcing a multi-section design onto pages with no structured content would have added unnecessary complexity and increased the risk of visual inconsistency with the template system’s default behaviour on subsequent builds.
3. QA cycle at template-customisation scale. A clean template customisation is not “build once, review once”. It is “build, QA, adjust, QA, adjust”. Of the 9 tasks tracked on this project, 7 were named QA iterations — individual rounds where the agency flagged design deltas, we reviewed, fixed, and returned the build for another review. Even on a compact 27-hour build, the loop density was high: the agency tracked items across two issue-backlog tabs (SEO and CX), which we worked through alongside the Redmine cadence.
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 time saving.
4. 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.
5. 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 the round’s design deltas, not the whole site, which is how a templated build stays efficient without losing coverage.
Tracking which elements were page-local versus template-global, across 20-plus pages sharing a single Service Page template, was the discipline that kept the build honest. The agency’s own QA catch — wrong doctor identity surfacing in the footer — confirmed that content-leakage on a reused template is silent until a reviewer reads the wrong name on the wrong page.
Operational Integrity at handoff
QA across the 7 iteration rounds caught template-level issues before each agency sign-off — the build ran through a structured review cycle on each of the 37 URLs, with each round closed only after the agency confirmed the delta was resolved. 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 | 37 — 1 homepage, 1 services lander, 20+ service pages (pediatric dental across Chastain, Kennesaw, and area-specific URLs), 1 doctor bio, 1 about, 1 contact, 1 blog lander, 1 blog post, 2 payment/insurance pages, 1 Spanish-speaking page, 3 legal pages |
| Templates applied | 16 of 16 reusable templates built and mapped across the 37 pages |
| Launch checklist | 85 items |
| QA / SEO / CX backlog rows tracked | 235 + 236 rows across the agency’s two issue-backlog tabs |
| Redmine QA iterations | 7 of 9 tasks (78%) tracked at the iteration level |
| Timeline | 50 days, delivered on schedule |
| Effort | 27 hours — no overrun, no scope creep |
| Team | 4 specialists |
| Hosting handoff | Live on the agency’s Kinsta template environment, then migrated to the client’s production domain |
| Production status | Site live at childrensdentistryofga.com — verified 200 OK at the time of this case-study draft |
The outcome, restated plainly: the agency’s Figma was implemented against their branded template across 37 mapped URLs and 16 templates, over 50 calendar days, inside the 27-hour estimate.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | ~3 days | Figma reviewed, template access confirmed, scope agreed (10–13 Nov) |
| Customisation development | ~1 week | Page-by-page template customisation to match Figma; initial pages built |
| QA iterations (concurrent) | ~4 weeks | 7 named QA rounds logged; each closed only on agency sign-off |
| Fix rounds | ~2 weeks | Post-review corrections, including logo-slider alignment and page updates |
| Post-release close | ~1 week | Final backlog reconciliation, invoice and payment close (30 Dec) |
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 — developer (template customisation and component fixes)
- Pavel Sazhin — QA iterations and sign-off passes
- Timur Arbaev — developer support on customisation rounds and QA fixes
- Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)
The partner agency held project management, design authority, content sourcing, and the end-client relationship from start to finish. Children’s Dentistry of Georgia never interacted with our team — the build moved through the agency’s shared issue backlog, and each round was released to the next only after their reviewer signed off on it.
For agencies with a branded template system
This engagement fits agencies that maintain a branded template on Kinsta or WP Engine and serve healthcare clients where the same Service Page template reuses across multiple locations and language variants. The risk on those builds is not visual drift — it is content-identity leakage that passes breakpoint QA and only shows up when a reviewer reads the wrong name or the wrong language on the wrong page.
If that’s your template stack, send a sample Figma and your location or language matrix. We will estimate the customisation hours, flag the content-identity risks before build starts, and return a fixed-hours quote within 24 hours. No cost. No obligation to proceed.
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.