47-Page Pediatric Dental Template Customisation

Client (end user): House of Smiles Pediatric Dentistry and Orthodontics — a Cypress, Texas pediatric and orthodontic practice
Engagement: White-label template customisation for a US marketing agency
Delivered: November 2025 · 106 days · 74 hours · 47 URLs · on schedule

The Craft of Template Customisation

A two-ladder pediatric and orthodontic practice — 28 service pages split across pediatric dentistry and orthodontics — customised from a 7-template Figma system with a phone-number typo seeded across the staging build from day one. With two divergent patient journeys sharing one Service Page template, every per-page check was load-bearing: the AutoQA audit caught the transposed digit (281-172-70511) propagated across all 47 pages before the agency signed off.

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 a pediatric dentistry and orthodontics site where two distinct service ladders (kids’ general dental care and orthodontic treatment for children, teens, and adults) had to live cleanly on the same template.

Snapshot

The Brief

A US marketing agency delivered us a Figma design for House of Smiles and a deployment target on their branded Kinsta-hosted template system. The agency had already done the upstream work: client requirements form, design audit, hosting setup, content plan and Google-Doc-per-page sourcing. 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 and pediatric-specific. Pediatric and orthodontic practices run two distinct service ladders on one site: a general pediatric dentistry tree (cleanings, sealants, pulpotomies, urgent care) and an orthodontics tree (early treatment, traditional and ceramic braces, clear aligners, retainers). Both had to be reachable from the same template, neither could outshine the other, and both had to read as kid-friendly, parent-trustable, and professionally credible — tonal calls the agency had already resolved in the Figma.

The exposure the agency was hedging against here is particular to two-ladder practices: the Service Page template gets reused 28 times across both ladders, which means a CTA string or form label applied correctly on the pediatric side can quietly propagate into the orthodontic side if the customisation is not precise. A “request an appointment” button appearing on an orthodontic treatment page instead of “schedule a consultation” is not a styling error — it routes the wrong patient journey at the wrong conversion moment. That kind of content error is not caught by a visual QA pass; it requires a deliberate per-page check of every templated element that carries patient-facing language.

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 be visually warm without being childish — and an orthodontic site that has to be clinically credible without being cold — that “no improvisation” rule mattered: every tonal call had already been resolved in the Figma.

2. Two-ladder service architecture, one template set. Pediatric dentistry and orthodontics each got their own services subtree under a shared services lander. The same Service Page template was used 28 times across both ladders — customised with ladder-specific copy, imagery, and the right next-step CTA (a sealant page leads to “request an appointment”; an orthodontics treatment page leads to “schedule a consultation”). Keeping those CTAs correctly assigned across 28 pages is template-level QA discipline, not a styling detail. Several items in the agency’s CX backlog were CTA-misroute corrections; the QA loop existed precisely to catch them.

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 24 tasks tracked on this project, 14 were named QA iterations (“-qa” suffix on the task title) — individual rounds where the agency flagged design deltas, we reviewed, fixed, and returned the build for another review. Behind those rounds was a much larger reconciliation: the agency tracked 175+ items across three issue-backlog tabs (SEO, DEV, and CX), the largest of which (DEV, 120 items) was carried by us through completion and QA.

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. The client-side content pipeline was not fully synchronised with the build timeline — several pages reached the staging environment with placeholder text and missing imagery because the practice’s notes had not been consolidated at the time of template customisation, and those gaps were resolved through the same 14-round QA loop rather than holding the build.

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. We chose per-page overrides over modifying the shared template components because preserving the template’s integrity for the agency’s next client mattered more than the marginal speed gain of editing the base layer directly.

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.

The QA loop was what made the Figma match deliverable at 47-page scale. Fourteen named iteration rounds — each requiring the agency’s sign-off before we moved to the next — held the build accountable to the design at every stage, including the phone-number audit that caught 281-172-70511 seeded across all 47 pages before the agency saw the final staging build.

Operational Integrity at handoff

Site Checker flagged two content-layer issues before the agency saw the final build: the fax number (281-727-0512) was surfacing in place of the main line (281-727-0511) across multiple blocks — caught by the phone-number audit — and Cyrillic text from a mid-build revision had leaked onto the live homepage and needed sanitization before handoff. 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 47 pages and 7 templates, over 106 calendar days, inside the 74-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 Pavel-tagged fix rounds
• Timur Arbaev — developer support on later customisation rounds and post-release tasks
• 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. House of Smiles 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