25-Page Dental Template Customisation in 103 Days — White-Label for a US Marketing Agency
25-page dental template customisation delivered over 103 days on Kinsta — 10 templates, 300+ tracked QA items, 55 hours across 5 specialists.
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
25 pages across 10 Figma-linked templates on a Kinsta dental template — 12 of those pages using one Service Page template, each with its own content, imagery, and CTA. Mid-engagement, the agency’s reviewers caught paragraph-bolding inconsistency across all 12 service pages and duplicate meta descriptions on each; both required a systematic pass, not a page-by-page spot fix. That is the real cost of applying one template twelve times: the fidelity check runs twelve times too.
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.
The same Service Page template applied twelve times, each with its own content, imagery, and layout variation — with a QA profile that matches what that repetition demands.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — General Dentistry |
| End-client | Centergate Family 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 | 25 URLs — homepage, about, services lander, 12 service pages, doctor bio, smile gallery, contact, blog lander + post, and 5 supporting pages (FAQs, financial info, forms, meet-the-team, schedule appointment) |
| Timeline | 103 days (14 Jul – 25 Oct 2025), on schedule |
| Effort | 55 hours — 25h development · 15h PM · 10h QA · 5h fixes |
| Team | 5 specialists |
| Templates | 10 reusable templates provided by the agency, all applied across the 25 pages |
| Tech Stack | WordPress · Elementor · Kinsta hosting · Figma-driven per-page design · agency AutoQA · Site Checker (xaverPRO QA plugin) |
| QA discipline | 300+ tracked SEO + CX issues reconciled in the agency’s backlog across a 73-item launch checklist |
| Engagement cadence | 60 agency-raised issues · all closed by handoff (36-day active span, 2025-08-05 – 2025-09-09) |
| Review rounds | ≈7 review rounds across the 103-day calendar window |
| Launch checklist | 73 items, signed off before cutover |
The Brief
A US marketing agency delivered us a Figma design for Centergate Family Dentistry and a deployment target on their branded Kinsta-hosted template system. The agency had already done the upstream work: design audit, client requirements capture, hosting setup, and content sourcing via Google Docs per service page. 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, raise findings back into the shared backlog, and return every iteration only after the agency-side reviewer had confirmed the delta was resolved. The 25-page scope included twelve service pages — each with its own Figma frame, content block, and imagery — that all shared the same underlying Service Page template. Some Figma frames specified visual treatments the template could not replicate directly, requiring CSS workarounds such as backdrop-filter overlays where the template components had no equivalent.
What the agency needed to guard against here was template-repetition fatigue. When one template is applied twelve times across a single practice’s service ladder, the risk is not a dramatic break — it is cumulative drift. The third service page matches the Figma, but by the eighth the spacing has slipped, the CTA block has drifted, and the image aspect ratio has silently changed. A dev partner that treats repeated template use as “copy and adjust” rather than “customise and verify” leaves the agency with a site that looks correct in aggregate but fails on the details that patients notice. The 305-item issue backlog on this project is the record of that check applied page by page.
Risk context. When one Service Page template is applied twelve times across a single practice’s service ladder, the failure mode is not a dramatic break — it is cumulative drift. The third iteration matches the Figma; by the eighth, spacing has slipped, the CTA block has shifted, and an image aspect ratio has quietly changed. A dev partner that treats repeated template application as copy-and-adjust rather than customise-and-verify leaves the agency with a site that looks correct at a glance but fails on the details patients and reviewers notice on close inspection.
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”. The agency tracked 305 items across two issue-backlog tabs (186 SEO findings and 119 CX findings), of which 85 were marked Completed at the time of handoff. Each round was a page-specific or site-wide review where the agency flagged design deltas, we reviewed, fixed, and returned the build for another pass.
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 more efficient handoff.
3. Customisation without drift. We documented every change we made to the branded template — whether to a page layout, a section component, or a style token — 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. Where effects such as translucent overlays fell outside the template’s native capability set, the team chose a CSS implementation over requesting a Figma revision — preserving the design intent without adding an agency-side approval cycle.
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.
Applying one Service Page template twelve times meant the fidelity check ran twelve times too. When the agency’s CX review caught paragraph-bolding drift across all twelve service pages, it required a systematic pass — not twelve individual fixes, but a single corrective sweep. That is what the constraint demands: the customisation work compounds with each repetition, and the verification load has to match it.
Operational Integrity at handoff
QA on this build carried the template-repetition load directly — the agency’s CX review caught paragraph-bolding drift across all 12 service pages, and the SEO tab caught an H-tag hierarchy error on the homepage. We signed off the 78-item pre-handoff checklist, including Trailing Slash Consistency and Status Codes, item by item before any page left staging. Pre-handoff QA ran through Site Checker — see how we run QA for the categories and the zero-defect bar each page had to clear. After handoff the agency ran its own review. We took each item it surfaced through 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 | 25 — 1 homepage, 1 services lander, 12 service pages, 1 doctor bio, 1 smile gallery, 1 about, 1 contact, 1 blog lander + 1 blog post, and 5 supporting pages |
| Templates applied | 10 of 10 reusable templates built and mapped across the 25 pages (Homepage, About Us, Services Lander, Service Page, Smile Gallery, Doctor Page, Contact Us, Blog Lander, Blog, Default Template) |
| Launch checklist | 73 items signed off |
| QA / SEO + CX issues tracked + resolved | 305+ items reconciled across the agency’s two issue-backlog tabs (186 SEO + 119 CX), 85 marked Completed at handoff |
| Timeline | 103 days, delivered on schedule |
| Effort | 55 hours — no overrun, no scope creep |
| Team | 5 specialists |
| Hosting handoff | Live on the agency’s Kinsta template environment |
| Page health at handoff | 25 / 25 staging URLs returned HTTP 200 in the sitemap audit |
Where this settled: we implemented the agency’s Figma against their branded template across 25 pages and 10 templates, over 103 calendar days, inside the 55-hour estimate.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | ~3 days | Figma reviewed, template access confirmed, scope agreed |
| Customisation development | ~6 weeks | Page-by-page template customisation to match Figma; service and supporting pages built |
| QA iterations (concurrent) | ~8 weeks | Multiple QA rounds logged; each closed only on agency sign-off |
| Fix rounds | ~2 weeks | Post-review corrections, content updates, image additions |
| 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
- Anna Polunina — developer support on content and image rounds
- Timur Arbaev — development support
- Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)
Centergate Family Dentistry only ever dealt with the agency. Every customisation request reached us through the agency’s shared backlog, and every iteration went back the same way — released only once the agency-side reviewer confirmed the changes were resolved to spec. The practice saw a single team carrying its brand; the agency kept the account, and we kept the build correct under it.
For agencies with a branded template system
On a branded template system, the gap between the design spec and the deployed page grows with every reuse. For this practice — a single-location dental clinic; for others — a multi-location group adapting the same template with localised copy. Spacing drifts between template instances — the third page matches spec, but by the eighth the margins have silently shifted. CTA blocks break alignment — the booking panel appears correctly on early versions but drops below the fold on later applications. Image aspect ratios change without a review flag — a provider photo crops awkwardly when the template resizes containers differently across the service ladder.
The question to ask a dev partner before committing is not “can you apply the template?” — it is “how exactly will you audit every instance against the brand spec?”
Send us the template source or template ID and your brand spec. We will walk every instance against the spec, identify where consistency is guaranteed to break down, and return a fixed-hours quote. No charge for the review; the quote comes back in hours, not a range.
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.