42-Page Dental Template Customisation
Figma-to-template customisation across 42 pages and 11 templates for a dental practice — 120+ QA items closed in 103 hours over 7 review rounds.
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): Rivers Dentistry — a US dental practice
Engagement: White-label template customisation for a US marketing agency
Delivered: November 2025 · 79 days · 103 hours · 42 URLs · on schedule
The Craft of Template Customisation
42 pages of a Colorado dental practice built from the agency’s dental-template12, with four licensed typefaces — Helvetica Neue, Proxima Nova, Brandon Grotesque, and Magister — that had to be sourced before the build could match the Figma. The QA pass surfaced template-residue content from a different practice still live on launch-critical pages; clearing it and closing 120 tracked issues across an 86-item checklist was the work the 79-day engagement required.
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.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — General Dentistry |
| End-client | Rivers Dentistry (US dental practice) |
| 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 | 42 URLs — homepage, about, services lander, 23 service pages, doctor bio, contact, blog lander + post template, smile gallery |
| Timeline | 79 days (19 Aug – 6 Nov 2025), on schedule |
| Effort | 103 hours — 41h development · 43h QA iterations · 15h PM · 4h fixes |
| Team | 4 specialists |
| Templates | 11 reusable templates provided by the agency, all applied across the 42 pages |
| Tech Stack | WordPress · Elementor · Kinsta hosting · Figma-driven per-page design · agency AutoQA (Links / Email / Content AI checks) · Site Checker (xaverPRO QA plugin) |
| QA discipline | 120+ tracked SEO + CX issues reconciled in the agency’s backlog across an 86-item launch checklist |
| Engagement cadence | 120 agency-raised issues · 118 of 120 closed by handoff (18-day active span, 2025-10-12 – 2025-10-29) |
| Review rounds | ≈7 review rounds across the 79-day calendar window |
| Per-ticket effort | 58 internal Redmine tickets · median 28m / P75 50m per ticket |
| Launch checklist | 39 items, signed off before cutover |
The Brief
A US marketing agency delivered us a Figma design for Rivers Dentistry 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 modify shared template components to hit a deadline — a shortcut that looks invisible until the agency discovers the same “fix” has degraded a different client’s site that rides the same template. A dental template in active use serves multiple practices at once; one project’s customisation cannot leak into the shared layer. That is the discipline the agency hired for, and it is what the 41-round QA loop on this project was built to verify.
Risk context. A dental template in active multi-client use is not owned by any single project. A dev team that modifies a shared component to hit a deadline on Rivers Dentistry does not just ship a Rivers Dentistry problem — it ships a silent degradation to every other practice whose site inherits that component. The failure does not appear in the project’s own QA pass; it appears weeks later, on a different client’s site, when the agency has already moved on. Keeping customisations strictly within per-client overrides is the only way to protect both the agency’s template investment and the clients who depend on it.
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 used per-client overrides rather than modifying the shared template components because the template served multiple practices simultaneously; a change to the shared layer would propagate silently to other clients riding the same template.
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 58 tasks tracked on this project, 41 were QA iterations — individual rounds where the agency flagged design deltas, 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 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 trade-off is that QA hours can outpace development hours — 43 of 103 project hours went to iteration — because every design deviation from the shared template required agency sign-off before the issue could close.
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.
The per-page Figma diff was the discipline that held this engagement together. Without it, design deltas would have accumulated across 41 review rounds rather than being caught at the page level — and the agency would have had no reliable way to verify that the customisation had not drifted into the shared template layer.
Operational Integrity at handoff
QA before handoff cleared two categories: content placeholders (lorem text on /new-patients and /technology, plus a sitewide image-placeholder gap across service pages), and a trailing-slash pass after internal links on /about and /dr-connor-rivers were found missing terminal slashes (Redmine #1008: «Too many issues incl lorem placeholders and links too claude»); 99 of 120 SEO-backlog items closed at 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
| Metric | Outcome |
|---|---|
| URLs delivered | 42 — 1 homepage, 1 services lander, 23 service pages, 1 doctor bio, 1 about, 1 contact, and 14 supporting pages |
| Templates applied | 11 of 11 reusable templates built and mapped across the 42 pages |
| Launch checklist | 86 items signed off |
| QA / SEO issues tracked + resolved | 120+ items reconciled across the agency’s two issue-backlog tabs (SEO and CX) |
| Redmine QA iterations | 41 of 58 tasks (71%) tracked at the iteration level |
| Timeline | 79 days, delivered on schedule |
| Effort | 103 hours against a 103-hour estimate — no overrun, no scope creep |
| Team | 4 specialists |
| Hosting handoff | Live on the agency’s Kinsta template environment |
| Page health at handoff | 40 / 40 staging URLs returned HTTP 200 in the sitemap audit |
The outcome, restated plainly: the agency’s Figma was implemented against their branded template across 42 pages and 11 templates, over 79 calendar days, inside the 103-hour estimate.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | ~3 days | Figma reviewed, template access confirmed, scope agreed |
| Customisation development | ~5 weeks | Page-by-page template customisation to match Figma |
| QA iterations (ongoing) | ~5 weeks | 41 QA rounds logged; each closed only on agency sign-off |
| Fix rounds | ~1 week | 4h on post-review corrections |
| 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
- Nikita Tumasevic — lead developer (template customisation and Figma-to-layout mapping)
- Pavel Sazhin — QA iterations and fixes
- Timur Arbaev — developer support on later customisation rounds
- 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, with nothing about the build exposed 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
If you have been burned by a dev team that customised your template by modifying shared components — shipping a fix for one client that silently degraded three others — the inverse is what this engagement demonstrates: per-client overrides only, every delta reconciled against the Figma before the round closes.
Send a sample Figma and your template URL. We will return a fixed-hours estimate, flag design elements that will need custom CSS rather than template-layer changes, and identify any drift risk — 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.