58-Page Dental Template Customisation
A 58-page dental template customisation for a new-practice launch — 8 templates, 35 service pages, 75 QA rounds across 76 days and 56 hours.
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): Cedar Pearl Dental — a US dental practice in Crestview, FL
Engagement: White-label template customisation for a US marketing agency
Delivered: February 2026 · 76 days · 56 hours · 58 URLs · on schedule
The Craft of Template Customisation
58 pages of a dental practice site mapped to the agency’s Figma across 8 reusable templates on Kinsta — 35 service pages, 7 geo-area pages, and supporting pages. Four URLs were rebuilt mid-project when the initial sitemap had assigned the wrong template type; rebuilding was required because the two template types carry different component structures. The agency owned the Figma and the template system; we owned the per-page execution and the QA loop that reached 75+ tracked items before handoff.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — General Dentistry |
| End-client | Cedar Pearl Dental (Crestview, 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 | 58 URLs — homepage, about, services lander, 35 service pages, 7 area-we-serve pages, blog lander, contact, and supporting pages |
| Timeline | 76 days (18 Nov 2025 – 2 Feb 2026), on schedule |
| Effort | 56 hours — development, QA iterations, and project management |
| Team | 6 specialists |
| Templates | 8 reusable templates provided by the agency, all applied across the 58 pages |
| Tech Stack | WordPress · Elementor · Kinsta hosting · Figma-driven per-page design · Site Checker (xaverPRO QA plugin) |
| QA discipline | 75+ tracked QA items reconciled across the agency’s feedback-preview and issue-backlog systems |
| Review rounds | ≈4 review rounds across the 76-day calendar window |
| Per-ticket effort | 103 internal Redmine tickets · median 10m / P75 25m per ticket |
| Launch checklist | 84 items, signed off before cutover |
The Brief
A US marketing agency delivered us a Figma design for Cedar Pearl Dental 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 a 58-page new-practice build as a bulk-copy exercise. With 35 service pages and 7 geo-area pages — all built from the same template set before the practice had a live patient base — the risk was not in the template customisation itself, but in letting placeholder content, empty blocks, or default imagery leak into pages that would be indexed by search engines before the client had final copy and photography ready. A dental template in active use serves multiple practices at once; one project’s customisation cannot leak into the shared layer, and neither can scaffold content leak into the live site. That is the discipline the agency hired for, and it is what the 75-round QA loop on this project was built to verify.
Risk context. A new dental practice launching on a branded template with 58 mapped URLs does not arrive with a full content kit for every page. The risk on this engagement was in preventing placeholder pages, empty galleries, and scaffold URLs from leaking into the live site before the client had images, copy, and policy language ready. A dev team that ships every sitemap row as “live” leaves the agency with 404s, orphan links, and placeholder headers in search indexes. The discipline here was in what we held back: pages without content were hidden at launch, Lorem ipsum blocks were stripped, and every visual delta flagged through the agency’s feedback preview system was reconciled before handoff. The practical limitation was that the blog could not launch at all — it was hidden from the header menu and excluded from the sitemap because the practice had zero posts ready, a constraint that persisted through delivery.
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. When the agency later reassigned several URLs from a “service lander” template to the “service page” template — because the initial sitemap mapping had assigned the wrong template type — we rebuilt those pages rather than patching the lander, because the two templates had different component hierarchies and patching would have created markup debt.
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 103 tasks tracked on this project, 75 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.
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 template-type check was what kept this build clean. Four pages had been assigned a service-lander template where a service-page template was required — the two carry different component hierarchies, and patching rather than rebuilding would have created markup debt across those URLs. Catching that during QA and rebuilding the four pages, not patching them, was the discipline that mattered.
Operational Integrity at handoff
QA on this build caught two categories of content error before handoff: the privacy-policy page carried the wrong client name — Cedar Smiles copy in a Cedar Pearl Dental page, caught in the first internal QA round — and four service URLs had been mapped to a service-lander template where a service-page template was required, flagged post-build and rebuilt rather than patched. 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 | 58 — 1 homepage, 1 services lander, 35 service pages, 7 area-we-serve pages, 2 about pages, 1 blog lander, 1 contact, and 10 supporting pages |
| Templates applied | 8 of 8 reusable templates built and mapped across the 58 pages (Homepage, About Us, Area We Serve, Blog Lander, Contact Us, Services Lander, Service Page, Default Template) |
| Launch checklist | 85 items signed off |
| QA / SEO issues tracked + resolved | 75+ items reconciled across the agency’s QA and feedback-preview systems |
| Redmine QA iterations | 75 of 103 tasks (73%) tracked at the iteration level |
| Timeline | 76 days, delivered on schedule |
| Effort | 56 hours against a 56-hour estimate — no overrun, no scope creep |
| Team | 4 specialists |
| Hosting handoff | Live on the agency’s Kinsta template environment |
| Page health at handoff | 58 / 58 staging URLs returned HTTP 200 in the sitemap audit |
The outcome, restated plainly: the agency’s Figma was implemented against their branded template across 58 pages and 8 templates, over 76 calendar days, inside the 56-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) | ~6 weeks | 75 QA rounds logged; each closed only on agency sign-off |
| Fix rounds | ~1 week | Post-review corrections, content holdbacks, visual 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
- Nikita Tumasevic — build review and QA support
- Pavel Sazhin — QA iterations and fixes
- Anna Polunina — template customisation support and QA
- Timur Arbaev — QA iterations and developer support
- Lyudmila Travkina — 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. All customisation requests came through the agency’s shared issue backlog; nothing about the build was visible 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 your agency has a Figma spec for an upcoming dental or local-business site and your template is already on Kinsta, send the Figma and your template access link. We will review it for template-type fit, flag any pages where the component hierarchy will require a rebuild rather than a patch, and return a fixed-hours estimate within 24 hours. 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.