Dental Template Customisation
A dental template customisation delivered in 64 days for a Bellevue practice. 4 QA rounds, ~32 hours total effort, content gaps held cleanly at launch.
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): Lifetime Smiles Bellevue — general and cosmetic dental practice, Bellevue, NE
Engagement: White-label template customisation for a US marketing agency
Delivered: December 2025 – February 2026 · 64 days end-to-end · ~32 hours total effort
The Craft of Template Customisation
Per-page Figma as the contract for a Bellevue dental practice — homepage, services, doctor bio, smile gallery, and contact pages customised inside the agency’s branded dental template on Kinsta. The engagement’s specific test: a before-and-after gallery section the Figma called for, but the practice had not yet supplied the photos (issue #2788). The discipline was to hold the section cleanly, not ship a non-functional button, and reopen through the post-launch backlog when content arrived.
This is a record of one such customisation, run inside the agency’s branded template, where the structural work was small and the discipline-against-content-gaps was the engagement’s specific shape.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — General and Cosmetic Dentistry |
| End-client | Lifetime Smiles Bellevue (general and cosmetic dental practice, Bellevue, NE) |
| Engagement | White-label template customisation for a US marketing agency specialising in local-business websites |
| Project Type | WordPress template customisation (agency’s branded dental template + per-page Figma design on Kinsta) |
| Scope | Homepage, services lander, service pages, doctor bio, contact, smile gallery, and supporting pages — customised against the agency’s Figma per-page reference; before-and-after gallery section coordinated through the backlog when client photo content was not available at launch |
| Timeline | 64 days (1 Dec 2025 – 2 Feb 2026), on schedule across main customisation + 4 internal QA rounds + post-launch backlog closure |
| Effort | ~32 hours total — 9.6h main customisation + 4 QA verification rounds (Pavel + Timur + xaver-ops cross-checks) + ~14h post-launch backlog closure across discrete CTA, OG-tag, address-position, and service-list fixes |
| Team | 6 specialists (development + QA + project management) |
| Templates | Agency’s branded dental template applied across the customised pages, with Figma-driven per-page design |
| Tech Stack | WordPress · Elementor · Kinsta hosting · Figma-driven per-page design · Site Checker (xaverPRO QA plugin) |
| QA discipline | 4 distinct internal QA rounds (Pavel-led, Timur-led, xaver-ops-led) followed by post-launch backlog tickets reconciled inside the agency relationship |
| Engagement cadence | 3 agency-raised issues · 2 of 3 closed by handoff |
| Review rounds | ≈4 review rounds across the 64-day calendar window |
| Per-ticket effort | 20 internal Redmine tickets · median 26m / P75 1.5h per ticket |
| Launch checklist | 84 items, signed off before cutover |
The Brief
The agency had a retained dental client in Bellevue, NE — a general and cosmetic practice operating under the Lifetime Smiles Bellevue brand. The agency owned the dental template; our job was to customise it page-by-page against the per-client Figma design and supply the site to staging on Kinsta, ready for the agency’s review cycle and eventual production cutover.
The ask was specific and characteristic of agency template work: take the template as the starting point, do not modify shared template components, customise per-site overrides only, follow the Figma design across each page, and surface anything missing through the agency’s shared issue backlog rather than improvising. Stay outside the client-facing loop throughout. Customisation requests, design clarifications, and end-client relationship management remain the agency’s territory.
Risk Context. The risk specific to this engagement was content-availability gap at customisation time. The Figma called for a before-and-after gallery section on the homepage with linked photo content. The practice had not supplied the photo set at the time the template was customised. A dev shop’s reflex on a content gap is to ship a placeholder section and call the customisation done — but a placeholder section with a non-functional button is a more visible regression at launch than a clean structural decision before launch. The discipline here was the inverse: surface the gap to the agency, coordinate a clean handling (hide the section, preserve the layout integrity), and reopen the work in the post-launch backlog when content arrives. A template customisation that ships a broken section because the spec called for one is not customisation discipline; it is template execution without judgement.
How We Did It
1. Per-page customisation against the agency’s Figma. The build worked through the agency’s branded dental template — homepage, services lander, individual service pages, doctor bio, smile gallery, contact, and supporting pages — applying the per-page Figma design as the authoritative reference. Where the template’s default arrangement differed from the Figma (phone number positioning, CTA layout, services list order on the homepage), the per-site overrides were applied without touching the shared template components that serve other practices on the same template system.
2. Content-availability gaps coordinated through the backlog. When the Figma’s before-and-after gallery section met the absence of supplied photo content, the section was held cleanly rather than shipped with a non-functional CTA. The agency’s shared issue tracker carried the coordination — not as a development blocker but as a structural-completeness item to revisit when client photo content arrived. The same discipline applied to several smaller items where the agency’s design called for content the practice had not yet finalised: address-position correction, services-list ordering on the homepage, OG-tag site-name correction.
3. Four-round internal QA cycle before sign-off. The QA pass moved through four discrete rounds across the engagement: a Pavel-led pass on 6 December, a xaver-ops cross-check the same day, a Pavel-led re-verification on 10 December, and a xaver-ops final pass on 20 December before agency handoff. Each round produced a triage list against the Figma; nothing closed until the next QA round confirmed the previous round’s fixes had landed cleanly without introducing new deltas.
4. Post-launch backlog closure inside the relationship. After agency handoff, a sequence of focused fix tickets came back through the shared backlog — the OG tag missing the website name, the main CTA button mismatched with the Figma template, the phone number and address in the wrong position, the homepage’s services list incomplete, the before-and-after gallery’s CTA not yet linked. Each ticket was scoped, fixed, internally QA’d, and released for agency-side reviewer sign-off. The post-launch tail is the engagement’s discipline-evidence: structural completeness was preserved at launch by holding gaps cleanly; the gaps closed cleanly through the relationship rather than through visible regressions.
Holding the before-and-after gallery section cleanly at launch — rather than shipping a non-functional CTA when client photos had not arrived — was the discipline that mattered here. Issue #2788 («Get before & after photos: Button not linked») stayed in the agency backlog until content arrived; the section reopened only when the asset was ready. That structural patience preserved the handoff quality on every other page.
Operational Integrity at handoff
The first QA pass on 6 December caught a sticky-header legibility issue — the header was semi-transparent at scroll and «нечитабельный в залипшем состоянии» (illegible in the sticky state) — fixed before handoff; three further agency tickets post-launch (RankMath OG-tag site name, main CTA button padding vs Figma, header phone-and-address position) closed through the shared backlog. 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 |
|---|---|
| Timeline | 64 days (1 Dec 2025 – 2 Feb 2026) — main customisation + 4 QA rounds + post-launch backlog closure, all on schedule |
| Effort | ~32 hours total — 9.6h main customisation + ~14h post-launch fixes + QA cross-checks |
| QA cycle | 4 internal QA rounds before agency sign-off — Pavel, Timur, and xaver-ops cross-verification |
| Post-launch fix tickets | OG tag site-name, CTA button alignment to Figma, phone-number and address positioning, homepage services list, before-and-after gallery CTA linking — each individually scoped, fixed, and verified |
| Content-gap handling | Before-and-after gallery section held cleanly at launch (no broken CTA shipped); ticketed for content-arrival reopening through the agency backlog |
| Cross-device QA | Customisation verified across desktop and mobile viewports through the QA cycle |
| Handoff | Site live on Kinsta after agency-side sign-off; no blocking issues at handoff |
The outcome, restated plainly: the agency’s template customisation discipline was preserved end-to-end. Per-page Figma fidelity, content-gap discipline, and post-launch ticket closure all moved through the agency relationship — the practice never interacted with our team directly.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & template review | ~1-2 days | Agency Figma + template reviewed; per-page customisation list prepared |
| Main customisation | ~2 weeks | Pages customised against Figma; content gaps surfaced through the backlog |
| Internal QA — round 1 | 6 Dec | Pavel-led QA pass; xaver-ops cross-check same day |
| Internal QA — round 2 | 10 Dec | Pavel-led re-verification of round-1 fixes |
| Internal QA — round 3 | 20 Dec | xaver-ops final pass before agency handoff |
| Agency handoff | Late December | Site delivered to staging for agency review |
| Post-launch backlog closure | January – early February | OG tag, CTA, address, services-list, gallery-CTA fixes ticketed and closed individually |
Team
Delivery team
- Nikita Tumasevic — lead developer (template customisation and Figma-to-layout mapping)
- Pavel Sazhin — QA lead (rounds 1 and 2, post-launch verification coordination)
- Anna Polunina — developer support (content updates, post-launch fix rounds)
- Timur Arbaev — QA support across the rounds
- Lyudmila Travkina — QA pass and pre-handoff review coordination
- Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off coordination)
Agency-side project management, design, content sourcing, and the end-client relationship remained with the partner agency throughout. Lifetime Smiles Bellevue did not interact with our team directly. All customisation requests and post-launch tickets came through the agency’s shared issue backlog; nothing about the build was visible to the end client.
For agencies with a branded template system
First engagement is typically a single-practice customisation at fixed hours — Figma reference, per-page scope, and any known content gaps identified upfront. If your agency has a customisation ready to scope, send the Figma package and a brief on known content gaps; we will return a fixed-hours estimate 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.