17-Template WordPress Library — Dental & Veterinary

Engagement: Long-term template-library development for a US marketing agency
Delivered: December 2024 – February 2026 · 14 months · ~430 hours across build, design iteration, and QA chains

The Craft of a Template Library Build at Scale

17 templates — 15 dental, 2 veterinary — built on a rolling commission over 14 months for a US marketing agency running a national dental website service. Each template landed into a live library already in production use; a defect baked into any one template propagated forward into every client project that descended from it. The discipline was per-template Figma fidelity on isolated instances and — from Q4 2025 — a three-tier internal QA chain before each template entered the catalogue.

Snapshot

The Brief

A US marketing agency operates a national white-label dental and medical practice website service. When a new practice client is onboarded, the agency selects a template from its library and a customisation engagement begins. The library is the agency’s product — the upstream asset that every client project descends from. Maintaining and expanding it requires a dev partner who can work on a sustained, multi-month basis, delivering new templates at the agency’s commissioning cadence rather than a single contracted sprint.

In December 2024, the agency’s template library held seven dental templates, built in a prior engagement. The library needed to grow: more dental visual directions, internal pages developed beyond the existing homepages, and — in the second year — a new veterinary vertical to serve a segment of their clients whose practices treat companion animals.

The agency engaged us as their long-term template-development partner. The commissioning model was rolling: new templates were issued as the agency’s design team completed Figma files, typically with a per-template deadline of two to four weeks. Each template was its own Redmine issue; design iterations and the QA chain generated sub-issues against the parent template task.

How We Did It

1. Rolling commissioning across fifteen dental and two veterinary templates. Each template was initiated as a separate Redmine issue when the agency issued a Figma design file. The rolling, one-at-a-time cadence meant the team could not batch-optimise across templates: each new Figma arrived with its own deadline, and sequential efficiencies were not possible. Several Figma files were delivered with incomplete design notes for internal pages — visible in the Dental Template 16 build, where the team had to request the agency finish unresolved design comments before proceeding. Templates 1–4 and 6–7 began with internal-page development in early 2025 (issues in the February–April window), extending the homepage-only templates already in the library. Dental Templates 8, 9, and 10 followed in the April–July window; Templates 12–17 were commissioned in the July–December 2025 period. Veterinary Templates 1 and 2 were introduced in December 2025 and February 2026, extending the library into a second industry vertical. Each template occupied its own WordPress installation — separate admin, separate Elementor environment, separate Gravity Forms instance — a deliberate choice of isolated architecture over shared multisite, so that no template’s construction could bleed into another’s and a defect in one instance could not propagate unnoticed into the library’s downstream client work.

2. Internal-page development as the primary build unit. The early phase of the engagement focused on adding internal pages to templates that existed as homepages only. This was the structural gap in the library: without a full internal-page set (service pages, contact, doctor, blog, financing, default template), the agency’s developers could not reliably scaffold a full client site from the template. Systematically, for each template in turn, the team worked through the standard ten-page structure: Homepage · About Us · Doctor Page · Services Lander · Service Page · Blog Lander · Blog · Financing · Contact Us · Default Template. Each page had to match the Figma faithfully at component level — not just the headline layout, but the typography scaling, button behaviour, mobile breakpoints, and any template-specific components (e.g. custom slider patterns, icon treatments, section nesting).

3. Design iteration rounds when the agency updated the Figma. For Templates 2, 4, 6, and 7, the agency issued updated Figma files after initial build — changes to homepage layouts, button hover states, or section proportions based on reviewer feedback. These generated dedicated iteration-round tasks (labelled “Iteration 2. Design updates for Template #N” in Redmine). The discipline was the same: work from the updated Figma at component level, validate changes against the prior build, close the round. This pattern — build → agency review → design update → revision build — reflects the real lifecycle of a template library: designs evolve as the agency calibrates what sells, and the library has to track those changes without accumulating permanent drift between the Figma spec and the deployed template.

4. Systematic per-template QA chain formalised in Q4 2025. As the library grew beyond ten templates and began incorporating the higher-hour dental templates (Templates 13–17 ranged from 7h to 35h per build), the agency formalised its review process into a structured three-stage QA chain. Each template build that cleared the developer’s own internal check was handed off to a QA reviewer (Timur Arbaev), who issued a dedicated sub-issue in Redmine with their findings. Timur’s fixes were then reviewed and cleared by a second reviewer (Pavel Sazhin) before the task moved to “sent, awaiting response” — the final stage before the agency added the template to the live library. The evidence in Redmine is the per-template QA sub-issue naming pattern: each carries the reviewing team member’s name and a date stamp (e.g. “Dental Template 16 — Timur-20260112-qa”, “Dental Template 16 — Pavel-20251226-qa”, “Dental Template 16 — xaver-20260115-qa”). For the most complex templates in the final quarter, this QA chain generated three separate sub-issues per template — one per reviewer — with the full back-and-forth of build, flag, fix, re-review documented in each. This is not overhead; it is the mechanism by which a library template earns its place in a production catalogue.

5. Veterinary vertical: new page structures, different vocabulary. When the agency commissioned Vet Templates 1 and 2 in late 2025 and early 2026, the build discipline was identical to dental, but the page structure and vocabulary started from the beginning. Vet templates require a Doctor Page that houses veterinarians rather than dentists, a Services Lander appropriate to companion-animal care, and a default-page structure that avoids any dental-specific language. Both templates were built from Figma designs provided by the agency, with the same ten-page standard set — the underlying page structure is consistent across verticals; what changes is the framing appropriate to each. Vet Template 2 alone carried a 30-hour build estimate with its own three-tier QA review chain.

Seventeen templates over fourteen months, each on a separate WordPress instance — the isolation was the structural guarantee. A defect caught on one template stayed bounded; it could not propagate into another build already in progress or already in the library.

Operational Integrity at handoff

Pre-handoff QA on this template-library engagement ran a per-template review chain — developer review, then a dedicated QA pass with a Redmine ticket per template, then confirmation review — before each template was marked ready for the agency’s library. 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.

Results

Process

Phases overlapped — new templates were commissioned while prior templates were in QA or iteration rounds. The 14-month calendar span reflects sustained concurrent work, not a sequential queue.

Team

Delivery team

• Nikita Tumasevic — lead developer across the template library; primary Figma interpretation and Elementor implementation for the majority of dental and veterinary templates
• Timur Arbaev — QA reviewer; issued structured per-template QA sub-issues with findings and maintained re-review cycles until templates cleared
• Pavel Sazhin — confirmation reviewer; second-tier QA sign-off before templates were submitted to the agency
• Anna Polunina — implementation support and QA on selected templates, especially in the earlier phases
• Natalia Bogatel — developer on Vet Template 1
• Anton Hersun, xaverPRO — project lead; estimation, agency-side communication, commissioning cadence management, and final submission per template

Agency-side project management, design production, and client-facing decisions remained with the partner agency throughout. Our team was invisible to the end clients — there were no end clients on this engagement. The deliverable was the library itself.

For agencies commissioning WordPress template library work