Work / Templated / 43-Page Dental Template Customisation

43-Page Dental Template Customisation

A 43-page Figma-to-template customisation across 16 templates for a pre-launch practice. 53 hours, 472 QA items, 89 days — delivered ahead of the opening.

Industry Healthcare (Dental)
Engagement White-label · US marketing agency
Delivered 89 calendar days · on schedule
53h across 89 days
ranieridentistry.com · desktop
ranieridentistry.com · mobile

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 →

— The brief

Rebuild the site on a new stack. Implement the spec. Don't improvise. Hand it back ready for cutover.

Client (end user): Ranieri Dentistry — a US dental practice (Dr. Tanner Ranieri, Bonita Springs, FL)
Engagement: White-label template customisation for a US marketing agency
Delivered: February 2026 · 89 days · 53 hours · 43 URLs · on schedule

The Craft of Template Customisation

43 pages of a new Ranieri Dentistry site mapped against the agency Figma onto the Luminous template — a pre-launch build with no existing site and no phone number yet, opening in Bonita Springs in April 2026. The Figma was the only reference; the 16-template scaffold had to be handed to the content team mid-build while QA ran concurrently across a 472-item backlog.

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 as a pre-launch build — one where the absence of a live reference site put the QA process entirely on the Figma-to-template match, with no fallback anchor to compare against.

Snapshot

Field Value
End-client industry Healthcare — General Dentistry
End-client Ranieri Dentistry — Dr. Tanner Ranieri (Bonita Springs, FL)
Engagement White-label template customisation for a US marketing agency specialising in local-business websites
Project Type WordPress template customisation (agency’s branded Luminous template + per-page Figma design on Kinsta)
Scope 43 URLs — homepage, about, services lander, 26 service pages across five categories (preventive, restorative/general, cosmetic, orthodontics, emergency, holistic), doctor bio, blog lander, smile gallery, contact, and 8 supporting pages (membership, financing, insurance, policies)
Timeline 89 days (5 Nov 2025 – 2 Feb 2026), on schedule
Effort 53 hours — 23h development · 30h QA and fix iterations
Team 4 specialists
Templates 16 reusable templates provided by the agency, all applied across the 43 pages
Tech Stack WordPress · Elementor · Kinsta hosting · Figma-driven per-page design · agency AutoQA (Phone-Number / Links / Email / Content AI / visual checks) · Site Checker ( QA plugin)
QA discipline 472 tracked SEO + CX issues reconciled in the agency’s backlog across an 80-item launch checklist
Engagement cadence 3 agency-raised issues · 1 closed by handoff (1 open · 1 deferred)
Review rounds ≈6 review rounds
Per-ticket effort 87 internal Redmine tickets · median 17m / P75 26m per ticket
Launch checklist 80 items, signed off before cutover

The Brief

A US marketing agency delivered us a Figma design for Ranieri Dentistry and a deployment target on their Luminous-branded Kinsta template. Dr. Tanner Ranieri’s practice was preparing to open in Bonita Springs, FL — the website had to be built and ready ahead of the April 2026 opening date, with no existing site to reference. The agency owned the design, the content pipeline, and the client relationship. Our scope was to implement the homepage from the Figma, extend the design across all page templates, and scaffold the full 43-page sitemap so the agency’s content team could continue populating pages while development was still in progress.

The operational ask had two layers. First, build the homepage and enough template pages (one per template type) for the content team to start work in parallel. Second, carry the full service taxonomy — 26 pages across preventive, general, cosmetic, orthodontic, emergency, and holistic dentistry — through to a QA-cleared state before launch. The agency tracked everything in a shared backlog; each item came back to us for a fix round and a re-check before it could close.

The risk profile of a pre-launch build is different from a rebuild. On a rebuild, the existing live site is the baseline — a missed page or a content discrepancy against the original site is verifiable. On a pre-launch build, the Figma is the only reference. Every design-match question bottoms out at “does this match the Figma, not the live site.” That makes visual fidelity the load-bearing discipline: a mismatched icon set, a hero image that deviates from the design, or a header that is not fixed at scroll — none of these have a live-site regression to surface them. They appear only through the QA loop. For this engagement, the agency’s AutoQA pass (which included a visual check using OpenAI’s GPT model across 1920, 1280, and mobile viewports) added a second layer of visual scrutiny that is not part of every Templated project. The 472-item issue backlog on this project reflects a QA process calibrated for a first launch with no prior site to anchor it.

Risk context. A pre-launch build has no live site to anchor QA against. On a rebuild, a missed element or a content discrepancy shows up as a regression from a known baseline. On a first-ever site, there is no baseline — the Figma is the only reference, and every design-match question bottoms out at “does this match the design, not the practice’s previous web presence.” That makes the QA loop the sole safeguard: a mismatched icon set, a hero image that deviates from spec, or a header that does not stay fixed on scroll are invisible until something in the review cycle catches them. A 43-page taxonomy built for a practice that has not yet opened — where the site has to be ready ahead of an April 2026 launch — has no tolerance for a truncated QA pass.

How We Did It

1. Figma-as-contract, template-as-canvas. The Figma design for the homepage was the build target. The Luminous template was the canvas. The first delivery was the homepage built to the Figma, with fonts, styles, and the global design system extended across all templates. After homepage approval, each template got one representative page built out — the content team’s signal to begin their parallel content work. No design decisions originated on our side.

2. Parallel template scaffold and content team handoff. The agency specified a split workflow: build templates, hand off to the content team, continue full-site build concurrently. The six technical-page URLs (membership, finance information, insurance, privacy policy, terms and conditions, disclaimer) needed a default secondary template with a hero block and full-width text — simple in structure but a deliberate scope boundary, not an afterthought. The scaffold was handed off in the same delivery wave as the designed templates so the content team’s work was not blocked by development order.

3. QA cycle at template-customisation scale. With 87 Redmine tasks tracked and 472 line items in the agency’s issue backlog (236 SEO and 236 CX), this engagement ran a QA loop that was both wide in scope and fine-grained in focus. Recurring classes of issues: icon sets that did not match the Figma, hero images that deviated from the design specification, a header that needed to be fixed on scroll, broken or missing links, the absence of client-supplied assets (doctor photo, phone number, insurance list) that had to be treated as intentional placeholders rather than errors. Each item was triaged — some resolved immediately, some held for client asset delivery, some addressed through interim placeholder states — and each closed only after the agency-side reviewer confirmed the delta.

4. Customisation without drift. Despite the high issue volume, all customisations stayed in per-client Elementor overrides. The Luminous template’s shared components were not modified. A practice that opens in April 2026 is not the last site the agency will deploy on this template; the 43 pages built for Ranieri Dentistry cannot introduce regressions into the shared layer that surface on the next client’s site.

5. Cross-device verification. The agency’s AutoQA Setup included a visual check at 1920, 1280, and iPhone 15 emulation viewports — a more thorough visual-fidelity gate than standard link and email audits alone. Our Site Checker pre-handoff pass confirmed multi-resolution correctness at staging before handoff; the agency’s post-handoff visual checks then surfaced the remaining pixel-fidelity findings for the fix loop. Text-on-background contrast issues identified late in the engagement (text mixing with hero images on certain blocks) were traced to layout choices that only became visible at specific viewport widths, and were resolved in the final fix rounds.

No live site meant the Figma was the only QA anchor — no baseline to regression-check against, no existing page to compare. That constraint ordered everything: the build had to be tight enough that the QA loop could catch a mismatched icon, a font that hadn’t loaded, a header not fixed on scroll. The 472-item backlog is what holding that standard looks like across 43 pages on a first-ever site.

Operational Integrity at handoff

Pre-handoff QA on this engagement had no live baseline to anchor against — the Figma was the only reference, and the fix loop surfaced exactly what that context predicts: a hero image that deviated from the design spec (Redmine #2014), incorrect icon sets across service pages (#2017), a header that was not fixed on scroll (#2018), and text-on-hero contrast that required three separate fix rounds. 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 43 — 1 homepage, 1 services lander, 26 service pages, 1 doctor bio, 1 about, 1 blog lander, 1 smile gallery, 1 contact, and 10 supporting pages (membership, financing, insurance, policies)
Templates applied 16 of 16 reusable templates built and mapped across the 43 pages
Launch checklist 80 items signed off
QA / SEO issues tracked + resolved 472 items reconciled across the agency’s two issue-backlog tabs (236 SEO and 236 CX)
Redmine QA iterations 62 of 87 tasks (71%) tracked at the QA iteration level
Timeline 89 days, delivered on schedule ahead of the April 2026 practice opening
Effort 53 hours across development, QA, and fix iterations
Team 4 specialists
Hosting handoff Live on the agency’s Kinsta template environment
Page health at handoff 37 / 43 staging URLs returned HTTP 200 in the sitemap audit (6 pages pending content delivery at snapshot time)

The outcome, restated plainly: the agency’s Figma was implemented against the Luminous template across 43 pages and 16 templates, over 89 calendar days, inside the 53-hour estimate — and delivered before a practice that had not yet opened for business.

Process

Phase Duration Outcome
Brief & estimation ~3 days Figma reviewed, template access confirmed, scope agreed at 20h core
Homepage + template scaffold ~1.5 weeks Homepage built to Figma; one page per template handed to content team
Full-site customisation ~3 weeks All 43 pages built out across 16 templates
QA iterations (concurrent) ~6 weeks 62 QA rounds logged; each closed only on agency sign-off
Asset integration and final fixes ~2 weeks Doctor photo, icon corrections, contrast fixes, placeholder states resolved

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

  • Evgeniy Karpov — lead developer (homepage build, full-site template customisation)
  • Nikita Tumasevic — developer support (late-stage fixes and icon corrections)
  • Pavel Sazhin — QA iterations and issue triage
  • Timur Arbaev — QA review rounds
  • Anna Polunina — implementation support and QA
  • Anton Hersun, — project lead (estimation, agency-side communication, sign-off)

Agency-side project management, design, content sourcing, and client communication remained with the partner agency throughout. Every customisation request arrived through the agency’s shared issue backlog; the end client had no direct view of our work. QA rounds closed only after the agency-side reviewer confirmed each delta was resolved.

For agencies with a branded template system

If you have a Figma spec and a Kinsta-hosted template, send both. We will review the design for customisation scope, identify anything that deviates from the shared template in a way that could create drift risk, and return a fixed-hours estimate within 24 hours. No cost for the review. No obligation to proceed.

Request a spec review →

Don't have a spec yet? Send a one-paragraph description — we'll come back with the questions worth asking. Send a description →


— Pre-handoff QA gate

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.

Core settings verificationpass
Content & SEO surface auditpass
URL structure integritypass
Content-language sanitizationpass
Menus & widgets auditpass
Original-vs-rebuild content diffpass
Multi-resolution screenshot capturepass
xaver.pro · 2026 White-label · Agency not named
Scroll to Top