22-Page Orthodontics Template Customisation
22-page orthodontics template customisation — 22 URLs, 8 templates applied, 102 QA issues closed in 58h. Agency Figma, on-schedule delivery.
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): McCullum Orthodontics — Dr. Heather McCullum, Jeffersonville, IN
Engagement: White-label template customisation for a US marketing agency
Delivered: February 2026 · 295 days · 58 hours · 22 URLs mapped, all built on staging · on schedule
The Craft of Template Customisation
22 pages of a brand-new orthodontics practice built from the agency’s Figma onto their dental template — no prior site, no existing URL surface, only the Figma as the QA baseline. The agency delivered the design spec; we delivered the per-page customisation, eight templates applied across a service taxonomy spanning adolescent and adult patient journeys. Discipline was in matching the Figma exactly while not drifting from the template’s shared components.
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 brand-new orthodontics practice site built from template scaffold to content-ready handoff, with no existing URL surface to regression-check against.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — Orthodontics |
| End-client | McCullum Orthodontics (Dr. Heather McCullum, Jeffersonville, IN) |
| 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 WP Engine) |
| Scope | 22 URLs — homepage, about, doctor bio, services lander, 8 service pages, financing lander + 2 sub-pages, contact, blog, thank-you, 404, legal pages |
| Timeline | 295 days (13 May 2025 – 2 Feb 2026), on schedule |
| Effort | 58 hours estimated — development, QA iterations, and project management |
| Team | 5 specialists |
| Templates | 10 reusable templates in the agency library, 8 applied across the 22 pages |
| Tech Stack | WordPress · Elementor · WP Engine hosting · Figma-driven per-page design · Gravity Forms · Site Checker (xaverPRO QA plugin) |
| QA discipline | 102 tracked issues reconciled in the agency’s backlog (50 SEO + 52 CX) across a 40-item launch checklist |
| Engagement cadence | 49 agency-raised issues · all closed by handoff (119-day active span, 2025-06-02 – 2025-09-28) |
| Review rounds | ≈15 review rounds across the 295-day calendar window |
| Per-ticket effort | 23 internal Redmine tickets · median 50m / P75 2.3h per ticket |
| Launch checklist | 39 items, signed off before cutover |
The Brief
A US marketing agency delivered us a Figma design for McCullum Orthodontics — an orthodontics practice in Jeffersonville, IN, offering braces, clear aligners, early intervention, retainers, and teeth whitening — and a deployment target on their branded WP Engine-hosted template system. The practice had no existing website; this was a brand-new build. 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.
Risk context. An orthodontics practice launching its first website has no live anchor to regression-check against — the only QA baseline is the Figma file. The risk the agency was hedging against was subtler than a broken migration: on a brand-new site, every template default that the Figma did not explicitly override becomes the patient’s first impression. Orthodontic treatment spans two distinct patient psychologies — adolescent early intervention (palatal expanders, space maintainers) and adult elective alignment (clear aligners, whitening) — and a template built for general dentistry does not automatically respect that split. The discipline required was in keeping the service taxonomy coherent across the template’s default structure while the agency’s content team filled the site post-handoff.
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.
2. QA cycle at template-customisation scale. A clean template customisation is not “build once, review once”. It is “build, QA, adjust, QA, adjust”. Over the course of this project, we tracked 15+ QA iterations in Redmine and reconciled 102 line items in the agency’s shared issue-backlog workspace — individual rounds where the agency flagged design deltas, missing images, and content inaccuracies, we reviewed, fixed, and returned the build for another review. 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 295-day calendar was driven by the agency’s review-and-approval cadence between rounds, not by development scope — the effective build time was approximately 58 hours, but each QA handoff waited on the agency’s internal cycle before the next iteration could close.
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.
3. 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.
4. Cross-device verification. Customisations were QA’d against Chrome, Firefox, Safari, and Edge on desktop, tablet, and mobile viewports. 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.
We used the agency’s existing template system as the foundation rather than building pages from scratch because it guaranteed design consistency across the practice’s service taxonomy — orthodontic treatment spans adolescent and adult patient types — and because every customisation had to stay confined to per-client overrides so the template library remained clean for future projects.
The Figma was not a static document. Colors were updated mid-project after client approval (issue #835), and the homepage banner and prototype were revised again in January 2026 — inside the same estimate. Treating each revision as a new iteration rather than scope expansion was what kept the 295-day engagement moving without renegotiating the hours.
Operational Integrity at handoff
On a brand-new orthodontics build with no prior URL surface, pre-handoff QA caught two traceable findings: a site-wide trailing-slash discipline rule applied to every internal link across all 22 pages, and a homepage typography reversal — the heading and subheading fonts were swapped against every other page in the build — surfaced in the final two-item QA close-out before sign-off. 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 | 22 — homepage, about, doctor bio, services lander, 8 service pages, financing lander + 2 sub-pages, contact, blog, thank-you, 404, legal pages |
| Templates applied | 8 of 10 reusable templates built and mapped across the 22 pages |
| Launch checklist | 40 items signed off |
| QA / issues tracked + resolved | 102 items reconciled across the agency’s issue-backlog tabs (50 SEO + 52 CX) |
| Redmine QA iterations | 15+ of 23 tasks tracked at the iteration level |
| Timeline | 295 days, delivered on schedule |
| Effort | 58 hours against a 58-hour estimate — no overrun, no scope creep |
| Team | 4 specialists |
| Hosting handoff | Delivered on the agency’s WP Engine staging environment; custom domain cutover agency-managed |
| Page health at handoff | 22 / 22 staging URLs provisioned and returning HTTP 200 |
The outcome, restated plainly: the agency’s Figma was implemented against their branded template across 22 pages and 8 templates, over 295 calendar days, inside the 58-hour estimate.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | ~2 days | Figma reviewed, template access confirmed, scope agreed |
| Customisation development | ~2 weeks | Page-by-page template customisation to match Figma |
| QA iterations (concurrent) | ~38 weeks | 15+ QA rounds logged; each closed only on agency sign-off |
| Fix rounds | ~2 weeks | Post-review corrections, banner and prototype updates |
| Delivery | final day | Site on WP Engine staging, ready for agency content fill and DNS cutover |
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
- Pavel Sazhin — QA iterations and fixes
- Anna Polunina — template customisation support and QA
- Timur Arbaev — QA iterations and developer support
- Natalia Bogatel — lead developer (template customisation and Figma-to-layout mapping)
- 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. Customisation requests came through the agency’s shared issue backlog; nothing about the build was visible to the end client. Each round was closed only when the agency-side reviewer signed off.
For agencies with a branded template system
This pattern fits agencies that maintain a branded template on WP Engine and run Figma-driven customisations that evolve through client approval cycles — where the Figma you hand off at kick-off is not the Figma you sign off on at launch. If that describes your pipeline, send a sample Figma and a link to your current template. We will estimate the customisation hours, identify where the design diverges from template defaults, and flag any revision-cycle risk before kickoff. 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.