Compact Dental Template Customisation in 46 Days, ~14 Hours — White-Label Delivery for a US Marketing Agency
A compact dental template customisation delivered in 46 days over the Christmas holiday window. 7 QA rounds, ~14 hours effort, no post-handoff fix list.
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
A 14-hour dental template customisation under a one-week holiday deadline — the brief on 18 December scoped finish by Wednesday the 24th, with two days runway for QA. Work started the same day and ran across Christmas and Boxing Day. What mattered was catching style inconsistency inside the Figma itself: a QA pass on 23 December flagged six consecutive sections each carrying a different title treatment. Seven QA rounds through the holiday window; no long post-handoff fix list.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — General Dentistry |
| End-client | Brown Dental (general dental practice, Atlanta, GA) |
| Engagement | White-label template customisation for a US marketing agency specialising in local-business websites |
| Project Type | WordPress template customisation (agency’s “dental-template10” branded 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 |
| Timeline | 46 days (19 Dec 2025 – 2 Feb 2026), on schedule across compact main customisation + 7 sequential QA verification rounds |
| Effort | ~14 hours total — 6.8h main customisation + ~7h across QA rounds and fix iterations |
| Team | 5 specialists (development + QA + project management) |
| Templates | Agency’s “dental-template10” branded 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 | 7 sequential QA verification rounds (in-house QA roster, sequential lead per round) across the holiday window — Dec 18 first pass through Jan 24 final pass |
| Review rounds | ≈4 review rounds across the 46-day calendar window |
| Launch checklist | 78 items, signed off before cutover |
The Brief
The agency had a retained dental client in Atlanta — Brown Dental, a general dental practice — and called for a customisation against the agency’s branded “dental-template10” template. The Figma per-page reference was supplied; our job was to customise the template to staging on Kinsta against that reference and move it through the agency’s review cycle to live cutover.
The ask spelled out the rules of template customisation: do not modify shared template components, customise per-site overrides only, follow the Figma design across each page, and return the site through the agency’s QA cycle for sign-off. Stay outside the client-facing loop throughout. Customisation requests, design clarifications, and the end-client relationship management remain the agency’s territory. The customisation window was one week before the first QA pass landed on 18 December — too compressed for template-level remediation of Figma inconsistencies, so the build proceeded with the ‘dental-template10’ baseline as-is.
Risk Context. The schedule shape on this engagement was compact and crossed a holiday window. The first pass landed on 18 December; the QA cycle ran across 26 December and 1 January through to a final 24 January pass. The risk specific to a compressed schedule on a small template customisation is not coverage — every page got built — but style-drift inside the Figma reference itself: when several sections in a row each carry slightly different title treatments, section-spacing rhythms, or H2 register decisions, a rushed customisation will reproduce the drift exactly. Catching style inconsistencies inside the Figma during the build, surfacing them to the agency, and correcting them mid-sprint is a different job from line-by-line Figma fidelity. On a holiday-cadence engagement where the QA reviewer is also moving through compressed time, the build team carries the load of style-coherence verification. A customisation that ships a faithful reproduction of an inconsistent Figma is not customisation; it is replication.
How We Did It
1. Per-page customisation against the agency’s Figma. The build worked through the agency’s “dental-template10” branded template, customising homepage, services lander, individual service pages, doctor bio, smile gallery, contact, and supporting pages against the per-page Figma reference. Per-site overrides held the customisation. We did not touch shared template components, preserving the template system’s integrity for other practices on the same template.
2. Style-drift catches mid-sprint. During the build, several places where consecutive Figma sections carried inconsistent treatments — different title styles within a single visual rhythm, mixed H2 registers across sequential sections, spacing inconsistencies that would read as visible drift on a desktop scan — surfaced during the customisation pass rather than at QA review. We raised each to the agency for a Figma decision rather than correcting it independently, because a self-directed fix that guessed the agency’s preferred resolution risked rework if the agency’s original intent was different — and the seven-pass QA cycle had no margin for a rework pass.
3. Seven-round sequential QA cycle across the holiday window. The QA cadence was unusually dense for the engagement size: an initial Pavel-led pass on 18 December, a xaver-ops cross-check on 19 December, a Pavel-led re-verification on 26 December (Boxing Day), a Timur-led pass the same day for breadth coverage, a xaver-ops pass on 26 December as the third reviewer, a 1 January pass to verify the holiday-window fixes had landed, and a final 24 January pass before agency sign-off. Each round produced a triage list against the Figma. Nothing closed until the next round confirmed the previous round’s fixes had landed cleanly without introducing new deltas.
4. Holding the compressed schedule through the agency relationship. The post-launch backlog stayed thin — the dense QA cadence absorbed the corrections that on a longer-schedule engagement might have surfaced as post-launch tickets. The proof here is the QA cycle density (7 rounds across a 46-day window) and the absence of a long post-launch tail. The engagement closed on the agency’s compressed cadence rather than spilling into a fix-loop after handoff.
Seven QA rounds across 38 days — starting 18 December and closing 24 January — every pass confirming the previous round’s fixes had landed before the next reviewer opened the site. The dense cadence was what absorbed the corrections; there was no post-handoff fix loop because there was no room for one inside a deadline that had to clear Christmas.
Operational Integrity at handoff
The QA pass on 23 December caught the engagement’s defining finding: six consecutive Figma sections each carrying a different title treatment. We ran the fixes through Christmas Day and closed them in the final pass on Boxing Day, 26 December. Pre-handoff QA ran through Site Checker — see how we run QA for the categories and the rule that no page ships with an open finding. Post-handoff, the agency ran its own QA, and we cleared each item it surfaced to sign-off.
Customisations stayed in the per-client overrides. We did not modify the agency’s shared template components.
Results
| Metric | Outcome |
|---|---|
| Timeline | 46 days (19 Dec 2025 – 2 Feb 2026) — main customisation + 7 QA rounds + final agency sign-off, all on schedule across the holiday window |
| Effort | ~14 hours total — 6.8h main customisation + ~7h across QA rounds and fix iterations (one of the most compact Templated engagements in the corpus) |
| QA cycle density | 7 sequential QA rounds across 38 days — Pavel + Timur + xaver-ops cross-verification through Dec 18, 19, 26, 26, 26, Jan 1, and Jan 24 |
| Style-drift discipline | Inconsistent title and section-spacing treatments inside the Figma surfaced during the build, raised to the agency, and corrected before the next QA round |
| Post-launch tail | Thin — the dense QA cadence absorbed corrections inside the engagement window; no long fix-loop after sign-off |
| Cross-device QA | Customisation verified across desktop and mobile viewports through the QA cycle |
| Site status | Live on Kinsta at http://browndentalatl.com/. |
Put simply: a compact dental template customisation moved through a dense holiday-window QA cycle without spilling into a long post-handoff fix list. Holding that compressed schedule is the engagement’s story.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & template review | ~1-2 days | Agency Figma + dental-template10 reviewed; per-page customisation list prepared |
| Main customisation | ~5-7 days | Pages customised against Figma; style-drift inconsistencies raised mid-sprint |
| Internal QA — round 1 | 18 Dec | Pavel-led QA pass |
| Internal QA — round 2 | 19 Dec | xaver-ops cross-check |
| Internal QA — round 3 | 26 Dec | Pavel-led re-verification |
| Internal QA — round 4 | 26 Dec | Timur-led pass for breadth coverage |
| Internal QA — round 5 | 26 Dec | xaver-ops third-reviewer pass |
| Internal QA — round 6 | 1 Jan | Holiday-window fix verification |
| Internal QA — round 7 | 24 Jan | Final pass before agency sign-off |
| Agency handoff | Late January | Site delivered to staging for agency review |
Team
Delivery team
- Nikita Tumasevic — lead developer
- Pavel Sazhin — QA lead (rounds 1, 3 — initial pass and Boxing-Day re-verification) and developer support on fix iterations
- Anna Polunina — template customisation support and QA
- Timur Arbaev — QA support (round 4 breadth coverage, holiday-window verification)
- Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off coordination, xaver-ops QA passes across rounds 2, 5, 6, 7)
Agency-side project management, design, content sourcing, and the end-client relationship remained with the partner agency throughout. The practice in Atlanta dealt only with the agency it had retained; our work reached it as the agency’s deliverable. Every customisation request came through the agency’s shared issue backlog, and the practice signed off on the agency’s name, not ours.
For agencies with a branded template system
On a branded template system, the structural risk you carry is that customisations break when the template updates. For this practice — single-location dental practice adopting a template; for others — multi-location dental group rolling out the same template across clinics. The next vendor update will break your child-theme overrides. A brand colour the client edits in the customiser will stop short of hardcoded template fallbacks. Non-developer staff will lose access to template blocks hidden behind code.
The question to ask a dev partner before committing is not “can you customise the template?” — it is “how exactly will you scope the overrides so they survive the next template update?”
Send us the template source or template ID and your brand spec. We will review the customisation layer, pinpoint the overrides that will conflict with future updates, and return a fixed-hours quote.
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.