21-Page Dental Template Customisation
A 21-page dental template customisation shipped in 38 days — 6 templates applied across 21 URLs, 43 hours of effort, rebrand absorbed mid-build.
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): Coastal Cosmetic & Family Dentistry — a US dental practice in Pensacola, Florida
Engagement: White-label template customisation for a US marketing agency
Delivered: February 2025 · 38 days · 43 hours · 21 URLs · on schedule
The Craft of Template Customisation
21 pages of a dental template customisation to the agency’s Figma — 6 templates applied across a Pensacola practice that was actively rebranding while the build was in progress. New practice name, new logo, new brand colours, and a late-arriving hero image: every brand asset swap landed mid-build, against the same Figma reference, without touching the shared template structure beneath.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — General Dentistry |
| End-client | Coastal Cosmetic & Family Dentistry (Pensacola, Florida) |
| 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 | 21 URLs — homepage, services lander, 7 service pages, meet the dentist, our team, smile gallery, new patients, reviews, contact, appointment request, and supporting pages |
| Timeline | 38 days (17 Jan – 26 Feb 2025), on schedule |
| Effort | 43 hours — development, QA iterations, and project management |
| Team | 7 specialists |
| Templates | 6 reusable templates provided by the agency, all applied across the 21 pages |
| Tech Stack | WordPress · Elementor · WP Engine hosting · Figma-driven per-page design · Site Checker (xaverPRO QA plugin) |
| QA discipline | 20 tracked issues reconciled in the agency’s backlog across a 58-item launch checklist |
| Engagement cadence | 20 agency-raised issues · all closed by handoff (14-day active span, 2025-04-04 – 2025-04-17) |
| Review rounds | ≈5 review rounds across the 38-day calendar window |
| Per-ticket effort | 23 internal Redmine tickets · median 10m / P75 30m per ticket |
| Launch checklist | 57 items, signed off before cutover |
The Brief
A US marketing agency delivered us a Figma design for Coastal Cosmetic & Family Dentistry and a deployment target on their branded WP Engine template system. The agency had already done the upstream work: client requirements, design audit, hosting setup, and content sourcing. What they needed was a development team to map the Figma onto the template faithfully and sustain the QA loop for as long as the agency’s review process required.
The ask carried an extra variable: the practice was rebranding mid-engagement. The practice name, doctor lineup, logo, and brand colours all changed while the template customisation was already under way. What the agency needed to guard against was a dev shop that would bake the old brand into the template structure and then charge rework to unwind it. On a templated build, a rebrand is not a simple find-and-replace — it touches every page that carries the practice name, every doctor bio, every logo placement, every colour token tied to the template’s design system. The discipline required was to build the customisation so that brand assets could be swapped without destabilising the template structure beneath them. That is the value the agency hired for, and it is what the 20-item issue backlog on this project was built to verify.
Risk context. When a template customisation runs alongside an active rebrand — new practice name, new doctor lineup, new logo, new colour tokens — the failure mode is a dev team that hard-codes the old brand into template structure and then bills rework to reverse it. The agency was hiring for a customisation that could absorb upstream brand evolution in-flight: brand assets swapped without destabilising the template layer beneath them, and no iteration charged twice.
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 reconciled each page deviation individually rather than rebuilding the template to match the Figma outright, because preserving the agency’s shared template structure meant the customisation could absorb the rebrand without destabilising components across future template sites.
2. Rebrand discipline within a template customisation. Mid-engagement, the practice name changed, the doctor lineup was finalised, and new brand assets (logo, colours, staff photos) arrived in batches. Every change was applied against the Figma reference, not as an ad-hoc edit. When the homepage hero image, tagline, and doctor profile pictures arrived late, they were swapped into the existing customisation without touching the template’s shared components. The build absorbed the rebrand rather than being rebuilt by it.
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 23 tasks tracked on this project, 14 were QA or fix iterations — individual rounds where the agency flagged design deltas or content updates, we reviewed, fixed, and returned the build for another review. This volume is appropriate for a 21-page engagement with an active rebrand; 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 faster delivery.
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 that round’s design deltas, not the whole site, which is how a templated build stays efficient without losing coverage.
The practice name, doctor lineup, logo, and hero image all changed while the build was live in staging. We absorbed each swap against the Figma reference without touching the template’s shared components — Dr. Yee’s placement restructured, tagline updated to «Brighter Smiles, Beachside Comfort», brand tokens reapplied. The template structure held.
Operational Integrity at handoff
Pre-handoff QA on this engagement caught a stray-space URL in the phone link and stripped third-party copyright footers baked into the template — a visual-comparison pass and link crawl then verified all 21 pages before staging went to the agency. 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 services lander, 7 service pages, 1 meet the dentist, 1 our team, 1 smile gallery, 1 new patients, 1 reviews, 1 contact, 1 appointment request, and 5 supporting pages |
| Templates applied | 6 of 6 reusable templates built and mapped across the 21 pages (Homepage, About Us, Doctor Page, Service Page, Blog, Default Template) |
| Launch checklist | 58 items signed off |
| QA / SEO issues tracked + resolved | 20 items reconciled across the agency’s issue-backlog tab |
| Redmine QA iterations | 14 of 23 tasks tracked at the iteration level |
| Timeline | 38 days, delivered on schedule |
| Effort | 43 hours — no overrun, no scope creep |
| Team | 4 specialists |
| Hosting handoff | Live on the agency’s WP Engine template environment |
The outcome, restated plainly: the agency’s Figma was implemented against their branded template across 21 pages and 6 templates, over 38 calendar days, inside the 43-hour estimate — including a mid-build rebrand that the customisation absorbed without rework.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | ~2 days | Figma reviewed, template access confirmed, scope agreed |
| Customisation development | ~3 weeks | Page-by-page template customisation to match Figma |
| QA iterations (concurrent) | ~2 weeks | 14 QA and fix rounds logged; each closed only on agency sign-off |
| Rebrand asset integration | ~1 week | Logo, colours, doctor photos, and staff bios swapped into the live customisation |
| Delivery | final day | Site live on WP Engine |
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 — project management and QA iterations
- Anna Polunina — QA iterations and content-layout fixes
- Dmitry Belyaev — developer support (smile gallery and mobile display refinements)
- Evgeniy Karpov — development support
- Natalia Bogatel — QA and project coordination
- 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
If you’ve hired a dev shop that baked an old brand into template structure and then charged rework to unwind it mid-engagement, the inverse is the discipline we use — brand assets applied against the Figma reference so that a swap mid-build does not require rebuilding the template beneath it. Send a current Figma and a link to your template; we will return a fixed-hours estimate and flag any brand-token risks 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.