21-Page Orthodontics Template Customisation in 43 Days — White-Label for a US Marketing Agency
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.
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 78-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 |
| Launch checklist | 78 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 what 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 we 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 what 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, we documented every change to the branded template — whether to a page layout, a section component, or a style token — 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. We QA’d customisations 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) and SEO-surface hygiene (incorrect website name in RankMath), both of which ran through multiple closure rounds before we cleared the build. Pre-handoff QA ran through Site Checker — see our QA approach for the categories and the rule that nothing ships with an open defect. Once handed over, the agency ran its own checks. We cleared what it flagged before sign-off.
Customisations stayed in the per-client overrides. We did not modify the agency’s shared template components.
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 | 78 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 |
Net result: we implemented the agency’s Figma 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. To ABM Orthodontics, the work read as their agency’s own delivery. All customisation requests came through the agency’s shared issue backlog, and our work surfaced to the practice only as finished, agency-branded pages. We closed each QA round only after the agency-side reviewer confirmed the delta was resolved.
For agencies with a branded template system
An orthodontic practice site built on a shared branded template carries a risk that the practice looks interchangeable with other providers on the same system. For this practice—a compact single-location orthodontic specialty; for others—a multi-location general dental group where brand consistency outweighs per-service distinction. Overrides made to differentiate service pages will break silently on the next template update. The brand colour palette will stop propagating into hardcoded sections the first time the client edits a colour in the customizer. And editorial staff will encounter broken block-editor views because the template hides components behind code toggles.
The question to ask a dev partner before committing is not “can you build the template pages?” It is “how exactly will you scope client-layer overrides so they survive the next template update?”
Send us the template source or template ID and your brand spec. We will review the customisation layer against your brand spec, identify the points where overrides will fight future updates, and return a fixed-hours quote. The review is free.
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.