16-Page Dental Template Customisation

Client (end user): Cedar Smiles Dental — a US general dental practice in Somerset, NJ
Engagement: White-label template customisation for a US marketing agency
Delivered: January 2026 · 112 days · 48 hours · 16 URLs · on schedule

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

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 the Figma’s rendered icon set was used 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 were the discipline that kept that liability on the right 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 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. 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. Insurance-logo blocks, financing-widget sections, and membership-plan card layouts were customised 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. 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 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 the Figma’s rendered set was used 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; both findings were tracked into Redmine, iterated through fix rounds, and closed before the agency signed off. 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

The outcome, restated plainly: the agency’s Figma was implemented against their branded template across 16 pages and 12 templates, over 112 calendar days, inside the 48-hour estimate.

Process

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 did not interact with our team directly. Each iteration round was released only once the agency-side reviewer confirmed the changes matched the Figma.

For agencies with a branded template system