21-Page Orthodontics Template Customisation
A 21-page orthodontic template customisation with per-page icon and colour differentiation — 10 templates, 51 QA rounds, 39 hours across 43 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): ABM Orthodontics — a US orthodontic practice in Clearwater, FL
Engagement: White-label template customisation for a US marketing agency
Delivered: December 2025 · 43 days · 39 hours · 21 URLs · on schedule
The Craft of Template Customisation
21 pages of an orthodontics template customisation on the agency’s “Glowing” branded template — 11 service and treatment pages each specifying a distinct icon set and tri-colour combination in the Figma, 39 hours, 43 days. The agency flagged early that the template’s default icon set was repeating unchanged across every service page; the fix was to work through each page’s Figma frame and apply the per-page icon and colour variation the design required.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — Orthodontics |
| End-client | ABM Orthodontics (Clearwater, FL) |
| 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 | 21 URLs — homepage, about, doctor bio, 11 service/treatment pages, insurance, financing, membership, contact, and policy pages |
| Timeline | 43 days (18 Nov – 30 Dec 2025), on schedule |
| Effort | 39 hours — development, QA iterations, and project management |
| Team | 4 specialists |
| Templates | 10 agency-branded templates applied across the 21 pages |
| Tech Stack | WordPress · Elementor · Kinsta hosting · Gravity Forms · Rank Math · Figma-driven per-page design · agency AutoQA (Links / Email / Content AI / visual checks) · Site Checker (xaverPRO QA plugin) |
| QA discipline | 470+ tracked SEO + CX issues reconciled across the agency’s backlog across an 85-item launch checklist |
| Engagement cadence | 3 agency-raised issues · 2 of 3 closed by handoff |
| Review rounds | ≈5 review rounds across the 43-day calendar window |
| Per-ticket effort | 81 internal Redmine tickets · median 15m / P75 24m per ticket |
| Launch checklist | 84 items, signed off before cutover |
The Brief
A US marketing agency delivered us a Figma design for ABM Orthodontics 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.
What the agency needed to guard against was a dev shop that would treat an orthodontic template customisation as a bulk-fill exercise. An orthodontics site with 11 distinct service and treatment pages — each describing a different procedure, each with its own Figma frame — cannot afford to look like a copy-paste job. When the same icon set repeats across every service page and the same colour palette fades into monotony, the practice loses the visual credibility that the agency’s design was built to establish. That is the discipline the agency hired for, and it is what the 51-round QA loop on this project was built to verify.
Risk context. A compact orthodontic site built on a shared dental template faces a visual-homogenisation risk that a larger general-dental site does not: when identical icons and default colour sets repeat across 11 service and treatment pages, the practice looks templated rather than customised. The Figma for this engagement specified per-page icon variation — distinct icon sets and tri-colour combinations for each service — which means the QA loop had to verify visual differentiation at the component level, not just layout accuracy. A dev team that skips this step ships a site that reads as interchangeable with every other practice on the same template, which is the opposite of what the agency’s design investment was meant to achieve. A further limitation was content readiness: several service pages had to launch with non-clickable placeholder button states because the agency’s final copy and booking integration were not yet ready — a scope constraint tracked through BugHerd that was resolved over two subsequent QA rounds.
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. We chose strict Figma fidelity over interpreting the design against the template defaults because the agency’s per-page icon and colour palette was the key differentiator across 11 service pages — running the template’s default icon set would have collapsed every page into visual uniformity, which was precisely what the agency’s investment in per-page Figma frames was meant to prevent.
2. 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 81 tasks tracked on this project, 51 were QA iterations — 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 470+ items across two issue-backlog tabs (235 SEO findings and 236 CX findings). 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 quicker handoff.
3. Customisation without drift. Over the course of the project, 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 — 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.
51 QA rounds across 43 days, each tracking per-page icon-and-colour fidelity against the Figma frame rather than treating service pages as interchangeable. That pace — more than one iteration per calendar day on average — is what the per-page differentiation spec required; without it, the agency’s investment in 11 distinct Figma frames would have been invisible at launch.
Operational Integrity at handoff
Pre-handoff QA on this engagement was concentrated on two categories: visual-fidelity findings (icon sets repeating across service pages where the Figma specified per-page variation — Redmine #2121) and SEO-surface hygiene (incorrect website name in RankMath — #2122), both of which ran through multiple closure rounds before the build was cleared. 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 | 21 — 1 homepage, 1 about, 1 doctor bio, 11 service/treatment pages, 1 insurance, 1 financing, 1 membership, 1 contact, and 3 policy pages |
| Templates applied | 10 of 10 agency-branded templates built and mapped across the 21 pages (Homepage, About Us, Doctor Page, Service Page, Services Lander, Insurance, Financing, Payment Plan / Membership, Practice Area Lander, Individ. Practice Area Page) |
| Launch checklist | 85 items signed off |
| QA / SEO + CX issues tracked + resolved | 470+ items reconciled across the agency’s two issue-backlog tabs (235 SEO + 236 CX) |
| Redmine QA iterations | 51 of 81 tasks (63%) tracked at the iteration level |
| Timeline | 43 days, delivered on schedule |
| Effort | 39 hours against a 39-hour estimate — no overrun, no scope creep |
| Team | 4 specialists |
| Hosting handoff | Live on the agency’s Kinsta template environment |
| Page health at handoff | 21 / 21 completed URLs returned HTTP 200 in the sitemap audit |
The outcome, restated plainly: the agency’s Figma was implemented against their branded template across 21 pages and 10 templates, over 43 calendar days, inside the 39-hour estimate.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | ~2 days | Figma reviewed, template access confirmed, scope agreed |
| Customisation development | ~1 week | Page-by-page template customisation to match Figma |
| QA iterations (ongoing) | ~4 weeks | 51 QA rounds logged; each closed only on agency sign-off |
| Fix rounds | ~1 week | Post-review corrections, icon updates, spacing 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. All customisation requests came through the agency’s shared issue backlog; nothing about the build was visible to the end client directly. Each QA round was closed only after the agency-side reviewer confirmed the delta was resolved.
For agencies with a branded template system
This engagement pattern fits agencies that build orthodontics and dental sites on a shared Kinsta template and need per-page icon and colour differentiation delivered faithfully — where the Figma specifies distinct variations for each service page and the QA loop has to verify at that resolution, not just at the layout level. If that describes your template workflow, send a sample Figma plus your template link. We will estimate the customisation hours and flag any per-page variation risk before kickoff.
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.