Implant & Prosthodontics Template Customisation
31-page implant and prosthodontics template customisation delivered in 123 days — 10 templates, 420+ tracked QA items, ~73 hours across 6 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.
Client (end user): Premier Implant & Denture Center — a US implant and prosthodontics practice in the Savannah, Georgia area
Engagement: White-label template customisation for a US marketing agency
Delivered: November 2025 · 123 days · ~73 hours · 31 URLs · on schedule
The Craft of Template Customisation
31 pages of an implant and prosthodontics template customisation — agency template #3, per-page Figma spec on Kinsta, 13 Service Page instances covering surgical procedures (implants, All-On-4, full-mouth restorations) alongside routine general dentistry. Adobe Typekit fonts required sourcing before build could start. The 420+ issue-backlog items were the quality gate; the discipline was keeping specialty pages visually distinct from general-dentistry pages on the same template structure.
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 for an implant and prosthodontics specialty practice — a project where the service taxonomy spans both high-ticket surgical procedures and routine general dentistry, all built on the same agency template system.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — Dental (Implant & Prosthodontics) |
| End-client | Premier Implant & Denture Center (Garden City, GA) |
| 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 | 31 URLs — homepage, about, services lander, 13 service pages (implants, All-On-4, full-mouth restorations, oral surgery, restorative dentistry, and general dental services), smile gallery, technology, contact, blog lander, and supporting pages |
| Timeline | 123 days (22 Jul – 22 Nov 2025), on schedule |
| Effort | ~73 hours estimated — development, QA iterations, and project management |
| Team | 6 specialists |
| Templates | 10 reusable templates provided by the agency, all applied across the 31 pages |
| Tech Stack | WordPress · Elementor Pro · Gravity Forms · Kinsta hosting · Figma-driven per-page design · Site Checker (xaverPRO QA plugin) |
| QA discipline | 420+ tracked SEO + CX issues reconciled in the agency’s backlog across a 78-item launch checklist |
| Engagement cadence | 66 agency-raised issues · all closed by handoff (85-day active span, 2025-08-07 – 2025-10-30) |
| Review rounds | ≈9 review rounds across the 123-day calendar window |
| Per-ticket effort | 29 internal Redmine tickets · median 26m / P75 1.2h per ticket |
| Launch checklist | 78 items, signed off before cutover |
The Brief
A US marketing agency delivered us a Figma design for Premier Implant & Denture Center 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. 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 practice, led by Dr. William Verillo, serves the Savannah area with a clinical scope that straddles two distinct service tiers: high-ticket surgical and restorative work (dental implants, All-On-4, full-mouth restorations, oral surgery) alongside routine general dentistry (exams, fillings, crowns, extractions). The agency’s template system was built to serve both — one Service Page template applied 13 times across the site, customised per procedure for copy, imagery, and layout.
The ask was operationally open-ended in a way that a fixed-scope rebuild is not. 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.
Risk Context — The danger on a dual-tier dental template customisation is not in building the pages — it is in the template flattening the distinction between specialty and routine. When one Service Page template serves both implant-surgery pages and general-dentistry pages, a customisation that applies the same layout rhythm, imagery density, and CTA framing to both tiers weakens the practice’s specialty positioning. The agency needed a partner that would keep the template’s structural consistency while ensuring the implant-tier pages read as surgical-specialty content, not generic dental. A dev team that treats all service pages as interchangeable risks making a prosthodontics practice look like a family dentist — a credibility loss the agency’s client would feel in patient inquiries, not in build errors.
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. Dual-tier service architecture on a single template set. The practice’s service taxonomy splits into two tiers: surgical/restorative (implants, All-On-4, full-mouth restorations, oral surgery) and general/preventive (exams, fillings, crowns, extractions). The agency’s Service Page template was applied 13 times across both tiers. Our customisation work ensured each tier retained its distinct tone — surgical pages carried procedure-depth copy and specialist-framed CTAs; general-dental pages carried accessibility and family-care framing. The template provided the structure; the content and imagery customisations provided the tier distinction.
3. 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 29 tasks tracked on this project, 16 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 420+ items across two issue-backlog tabs (213 SEO findings and 210 CX findings), of which the majority were marked Completed at the time of handoff.
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.
4. 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. 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.
5. Cross-device verification. Customisations were QA’d against Chrome, Firefox, Safari, and Edge on desktop, tablet, and mobile viewports. 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 QA cycle was what made the dual-tier discipline hold. Of the 29 Redmine tasks, 16 were dedicated QA iterations — rounds where the agency flagged design deltas, we reviewed, fixed, and returned for another pass. Without that sustained loop against 420+ tracked items, the distinction between implant-surgery pages and general-dentistry pages on the same template structure would have collapsed into a uniform layout.
Operational Integrity at handoff
QA on this build’s 31-page staging environment caught two URL-structure findings before handoff — a slug typo on the doctor-profile page (/dr-william-verrillo vs the correct /dr-william-verillo) and unreplaced placeholder copy on /meet-the-team/ flagged for a full content review — both resolved before the agency saw the build. 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 | 31 — 1 homepage, 1 services lander, 13 service pages, 1 about, 1 contact, 1 blog lander, 1 blog post, 1 smile gallery, and 11 supporting pages (appointment, technology, reviews, office gallery, new patients, meet the team, dr. profile, privacy, terms, insurance, finance) |
| Templates applied | 10 of 10 reusable templates from the agency’s library (Homepage, About Us, Services Lander, Service Page, Contact Us, Blog Lander, Blog, Smile Gallery, Default Template, Doctor Page) |
| Launch checklist | 78 items signed off |
| QA / SEO + CX issues tracked + resolved | 420+ items reconciled across the agency’s two issue-backlog tabs (213 SEO + 210 CX) |
| Redmine QA iterations | 16 of 29 tasks (55%) tracked at the iteration level |
| Timeline | 123 days, delivered on schedule |
| Effort | ~73 hours estimated across the engagement — no overrun, no scope creep |
| Team | 5 specialists |
| Hosting handoff | Live on the agency’s Kinsta template environment |
| Page health at handoff | 31 / 31 staging URLs returned HTTP 200 in the sitemap audit |
The outcome, restated plainly: the agency’s Figma was implemented against their branded template across 31 pages and 10 templates, over 123 calendar days, inside the estimated hours.
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; dual-tier service pages built |
| QA iterations (concurrent) | ~10 weeks | 16 QA rounds logged; each closed only on agency sign-off |
| Fix rounds | ~3 weeks | Post-review corrections, content edits, placeholder-image swaps |
| 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 project coordination
- Anna Polunina — developer support on customisation and content rounds
- Evgeniy Karpov — development support
- Timur Arbaev — QA and fix rounds
- Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)
The agency held the end-client relationship throughout. All customisation requests moved through the agency’s shared backlog; Premier Implant & Denture Center did not interact with our team directly. Each iteration round was released only once the agency-side reviewer confirmed the changes were resolved to spec.
For agencies with a branded template system
This engagement fits agencies that maintain a branded template on Kinsta and run a Figma-per-client design workflow. If that is your shape, send a sample Figma and a link to your template — we will identify where the design requires customisation beyond the template’s defaults, flag anything that will cost more than it looks, and return a fixed-hours quote 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.