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.
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 hard part 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.
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 73-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 |
| Launch checklist | 73 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). We applied the agency’s Service Page template 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. 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.
5. Cross-device verification. We QA’d customisations 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 kept the two service tiers from blurring together. 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 how we run QA for the categories and what has to clear before a build leaves us. Post-handoff, the agency reviewed on its own setup, and we cleared each finding it raised up 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 | 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 | 73 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 | 6 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 gist: we implemented the agency’s Figma 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)
Premier Implant & Denture Center knew the agency as its web team and never heard our names. Every customisation request reached us through the agency’s shared backlog, and every fixed build went back the same way. We released each iteration round only after the agency-side reviewer confirmed the changes were resolved to spec — the practice in Garden City saw the agency’s sign-off, never our staging environment.
For agencies with a branded template system
On a multi-procedure implant specialty site, the template system dictates how each procedure type is presented — and that architecture is hard to bend later. For this practice — multi-procedure with surgical pathways and restoration categories; for others — single-procedure with one page type. The page-type hierarchy will collapse into one generic template, patient-education modules will break the component library, and the consultation CTA will map to the wrong visit type.
The question to ask a dev partner before committing is not “can you build the pages?” — it is “how exactly will you scope the page-type hierarchy to handle procedure-specific content without breaking the template?”
Send us your template source or template ID and your brand spec. We will walk the page-type hierarchy against your content types, check the component library for patient-education gaps, and return a fixed-hours quote. The review is free.
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.