Dental Template Customisation in 64 Days, ~32 Hours — White-Label Delivery for a US Marketing Agency
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.
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. The right call was to hold the section cleanly, not ship a non-functional button, and reopen through the post-launch backlog when content arrived.
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 |
| Launch checklist | 78 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 better move 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), we applied the per-site overrides 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, we held the section cleanly rather than shipping it 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 approach 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. We scoped, fixed, internally QA’d, and released each ticket for agency-side reviewer sign-off. The post-launch tail is the engagement’s discipline-evidence: we preserved structural completeness at launch by holding gaps cleanly, and the gaps closed 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 call that mattered here. That before-and-after section stayed in the agency backlog until content arrived, and 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 — which we 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 how we run QA for the categories and the zero-failures bar we hold before handoff. Once the agency had it, they ran their own QA and we cleared what they raised to sign-off.
Customisations stayed in the per-client overrides. We did not modify the agency’s shared template components.
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 |
| Site status | Live on Kinsta at https://lifetimesmilesbellevue.com/. |
Boiled down: we preserved the agency’s template customisation end-to-end. Per-page Figma fidelity, content-gap handling, and post-launch ticket closure all moved through the agency relationship — the practice fielded everything through the agency’s account manager and never needed to email us.
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 dealt with the agency for every approval and update, and our team carried no contact with the practice. All customisation requests and post-launch tickets came through the agency’s shared issue backlog. The practice saw the finished pages, not the people or the workflow that produced them.
For agencies with a branded template system
On a template-based dental site, the customisation layer carries a hidden risk — it can break when the template updates or when content is not ready. For this practice — single-location clinic; for others — multi-location group with a coordinated brand system. Three quiet failure modes. Child-theme overrides break when the template vendor pushes an update. Brand tokens stop propagating when the client edits a colour. Template blocks hidden from the editor force client staff to ship missing content as broken sections.
Ask a dev partner before committing: not “can you customise the template?” but “how will you isolate customisations from updates and handle content gaps?”
Send us your template source or template ID and your brand spec. We will audit the customisation boundary against the template core. We will pinpoint where updates break overrides and where content gaps cause regressions, then return a fixed-hours quote. Free review, fixed quote in hours.
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.