16-Page Dental Template Customisation in 112 Days — White-Label for a US Marketing Agency
16-page Figma-to-template customisation across 12 reusable templates in 112 days. 48 hours of development, 74-item checklist, 470+ tracked QA iterations.
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
16 pages mapped to the agency’s dental template against a Cedar Smiles Figma spec — homepage, two services landers, four service pages, about pages, doctor bio, and patient-conversion pages (insurance, financing, membership plan) across 12 reusable templates on Kinsta. The agency owned the Figma; we owned the mapping and QA. Deviation from the template’s defaults triggered a reconciliation pass — which is why 45 of 62 tracked tasks were QA iterations, not build work.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — General Dentistry |
| End-client | Cedar Smiles Dental (US dental practice, Somerset, NJ) |
| 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 | 16 URLs — homepage, services lander, 4 service pages (preventive, restorative, cosmetic, emergency), 2 about pages, doctor bio, contact, insurance, financing, membership plan, and 3 supporting pages (reviews, accessibility, privacy policy) |
| Timeline | 112 days (3 Oct 2025 – 24 Jan 2026), on schedule |
| Effort | 48 hours — development, QA iterations, and project management |
| Team | 4 specialists |
| Templates | 12 reusable templates provided by the agency, all applied across the 16 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 | 470+ tracked SEO + CX issues reconciled in the agency’s backlog across an 74-item launch checklist |
| Engagement cadence | 3 agency-raised issues · 2 of 3 closed by handoff |
| Review rounds | ≈8 review rounds across the 112-day calendar window |
| Launch checklist | 74 items, signed off before cutover |
The Brief
A US marketing agency delivered us a Figma design for Cedar Smiles Dental and a deployment target on their branded Kinsta-hosted template system. The agency had already done the upstream work: client requirements, design audit, hosting setup, and content sourcing via Google Docs per page. Some asset types arrived with format constraints — section icons were provided in non-SVG formats that could not be recolored to match the template’s palette, so we used the Figma’s rendered icon set instead — and certain service pages in the sitemap were flagged as out of scope (rows the client was not yet offering at the time of build). 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 was operationally precise. Customise the template to match the Figma page by page. Flag findings back into the shared backlog. Return every iteration only after the agency-side reviewer had confirmed the delta was resolved. The 16-page scope was the entry point; 112 days and 45 QA rounds is what it took to close it out.
A dental practice’s website is not just a brochure — its insurance, financing, and membership-plan pages are direct revenue surfaces. The agency needed a customisation partner who would not treat a 16-page build as light work. On this project, four core service pages carried nested sub-service architecture in the sitemap, and three supporting pages handled patient-conversion flows where an incorrect logo, a misrouted form, or a misplaced CTA would create a post-handoff liability. The risk the agency was hedging against was not volume but precision: a partner who stops iterating when the site looks roughly right leaves the agency owning every error on a page that directly affects patient acquisition. The 45 QA iterations and 470-plus tracked backlog items kept that liability on the right side of the line.
Risk context. A dental practice’s conversion pages — insurance acceptance, financing options, membership plan — are not brochure copy. They are revenue surfaces where a misrouted form or an incorrect logo creates a post-handoff liability the agency cannot walk back. On a 16-page build this small, there is no safety in numbers: each page carries disproportionate weight, and a partner who stops iterating when the site looks roughly right leaves the agency owning every error on a page patients consult before booking. The 45 QA iterations and 470-plus tracked backlog items were not overhead — they held that liability on the correct side of the line.
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. The template-copy approach — duplicating the agency’s branded template and customising it per-client rather than building each site from scratch — was the agency’s established delivery model. It accelerated page construction across the 16-URL scope but placed the full burden of correctness on per-page customisation: every Figma deviation that the template could not accommodate had to be manually reconciled in the QA loop, which is why 45 of the 62 tracked tasks were iteration rounds.
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 62 tasks tracked on this project, 45 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-plus items across two issue-backlog tabs (236 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 faster delivery.
3. Customisation without drift. We documented every change to the branded template — whether to a page layout, a section component, or a style token — against the Figma reference. We customised insurance-logo blocks, financing-widget sections, and membership-plan card layouts inside the page scope. No customisation propagated into the agency’s shared template components, which means this project’s changes did not affect any other site built on the same template.
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 that round’s design deltas, not the whole site, which is how a templated build stays efficient without losing coverage.
The non-SVG icon constraint forced the first decision: section icons arrived in raster formats that could not be recoloured to match the template’s palette, so we used the Figma’s rendered set instead — a substitution that had to hold across the three revenue pages (insurance, financing, membership plan) without introducing layout drift. That resolution kept the 45 QA iterations focused on design fidelity rather than format disputes.
Operational Integrity at handoff
The agency’s Feedback Plugin flagged a navigation bug on the homepage dropdown — a menu item rendering as “#2233 (NO TITLE)” instead of the page title — and broken links across the About Us and Meet Our Team pages. We tracked both findings into Redmine, iterated through fix rounds, and closed them before the agency signed off. Pre-handoff QA ran through Site Checker — see how we run QA for the categories and the zero-fail bar each page had to clear. Post-handoff, the agency reviewed on its own tooling, and we worked each finding it raised to sign-off.
Customisations stayed in the per-client overrides. We did not modify the agency’s shared template components.
Results
| Metric | Outcome |
|---|---|
| URLs delivered | 16 — 1 homepage, 1 services lander, 4 service pages, 2 about pages, 1 doctor bio, 1 contact, 1 insurance, 1 financing, 1 membership plan, and 3 supporting pages (reviews, accessibility, privacy policy) |
| Templates applied | 12 of 12 reusable templates built and mapped across the 16 pages |
| Launch checklist | 74 items signed off |
| QA / SEO + CX issues tracked | 470+ items reconciled across the agency’s two issue-backlog tabs (236 SEO + 236 CX) |
| Redmine QA iterations | 45 of 62 tasks (73%) tracked at the iteration level |
| Timeline | 112 days, delivered on schedule |
| Effort | 48 hours — no overrun, no scope creep |
| Team | 4 specialists |
| Hosting handoff | Live on the agency’s Kinsta template environment |
| Page health at handoff | 16 / 16 staging URLs returned HTTP 200 in the sitemap audit |
The headline: we implemented the agency’s Figma against their branded template across 16 pages and 12 templates, over 112 calendar days, inside the 48-hour estimate.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | ~3 days | Figma reviewed, template access confirmed, scope agreed |
| Customisation development | ~4 weeks | Page-by-page template customisation to match Figma; service and specialty pages built |
| QA iterations (concurrent) | ~12 weeks | 45 QA rounds logged; each closed only on agency sign-off |
| Fix rounds | ~1 week | Post-review corrections, insurance block refinements, menu updates |
| 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 — developer support on later customisation rounds
- Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)
The agency managed the end-client relationship throughout. All customisation requests moved through the agency’s shared workspace; Cedar Smiles Dental dealt only with the agency, and our name never reached the practice. We released each iteration round only once the agency-side reviewer confirmed the changes matched the Figma.
For agencies with a branded template system
A branded template system carries a hidden risk: the customizations that make the site unique silently break when the template vendor updates. For this practice—a single-location dental practice with conversion pages; for others—a multi-location group with a shared brand system and separate insurance catalogs. Without careful testing, customizations break on each template update, custom fields for forms drift out of sync, and brand tokens stop cascading into key pages.
The question to ask a dev partner is not “can you use our template?” — it is “how will you protect our customizations across template updates?”
Send us the template source or template ID and your brand spec. We will walk through the template source and brand spec, identify where your customizations risk breaking on the next update, 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.