99-Page Dental Template Customisation

Client (end user): Grand Oaks Dentistry — a US dental practice in Austin, TX
Engagement: White-label template customisation for a US marketing agency
Delivered: April 2025 · 60 days · 61 hours · 99 URLs · on schedule

The Craft of Template Customisation

99 URLs mapped across 10 agency templates — a legacy dental site on .html permalinks migrated to a fresh WP Engine install, Figma per page as the design contract. URL migration ran first: clean permalink structure, redirect map, missing-page audit. Mid-project, the client flagged staging as «unattractive, content not laid out professionally» — the design system had diluted in transit. The second half was restoring that fidelity against the template before the 58-item checklist could close.

The value is speed with consistency — but only if the customisation is disciplined. A dev team that “interprets” the design, skips QA rounds, or deviates from the template’s design system is worse than starting from scratch.

This case study is a record of a template customisation executed to the agency’s design, including a mid-project revision round that tested whether the team could restore the template’s visual promise without losing the content that had already been migrated.

Snapshot

The Brief

A US marketing agency delivered us a brief for Grand Oaks Dentistry: migrate an existing legacy site onto their branded WP Engine-hosted template system, preserving all content, metadata, and URL structure while adapting the practice’s brand to the new template’s design language. The agency had already done the upstream work: client requirements, template selection, hosting setup, and content sourcing. What they needed was a development team that would execute the migration faithfully and sustain the QA loop through however many rounds the design-match required.

The initial build progressed on schedule. Then the client reviewed the staging site and raised a concern that would reframe the second half of the engagement: the site did not look as professional as the template he had chosen. The issue was not functional — pages loaded, links worked, content was present. The issue was aesthetic fidelity. The template’s visual promise — its spacing, typography hierarchy, image treatment, and colour discipline — had been diluted during content migration. What the agency needed to guard against was a dev shop that treats template customisation as pure content migration, moving text and images from point A to point B without asking whether the result still looks like the template the client paid for. A template is a design system, not a container. The risk the agency was hedging against was the silent degradation of that system during migration.

How We Did It

1. Figma-as-contract, template-as-canvas. The agency’s design references and the branded template were the dual sources of truth. Our job was to reconcile them page by page — where the template’s default layout matched the design intent, we kept it; where the legacy content required a deviation, we customised. No design decisions originated on our side.

2. QA cycle at template-customisation scale. A clean template customisation is not “build once, review once”. It is “build, QA, adjust, QA, adjust”. On this project, the QA loop included a formal QA stage (responsive verification, link audit, meta-tag check, content correctness), followed by a client-driven revision round to restore template feel, followed by post-live fixes after the site was pushed to production before all staging updates had closed. Each round was tracked as a separate Redmine task and closed only on agency sign-off.

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.

3. Customisation without drift. Every change we made to the branded template — whether to a page layout, a section component, or a style token — was scoped to the per-client override layer. 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.

4. Cross-device verification. Customisations were QA’d 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 tension was a site that was functionally complete — pages loaded, links worked, content was present — but had lost the spacing and colour discipline that made the template worth choosing. Restoring it meant a second pass through the affected pages, checking each against the agency’s template reference before the corrected build went back to QA.

Operational Integrity at handoff

The internal QA stage ran the checklist — heading tags, title and meta tags, links, and responsive layout across desktop and mobile — before the first handoff; when the agency flagged that the build had drifted from the template’s visual promise, a second pre-resubmission pass ran the same checks against the revised pages to confirm design fidelity had been restored before the agency saw the corrected build. 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

The outcome, restated plainly: the agency’s template was customised across 99 pages and 10 templates, over 60 calendar days, inside the 61-hour estimate.

Process

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 migration execution)
• Pavel Sazhin — project management and QA iterations
• Anna Polunina — QA iterations and template-feel restoration
• Evgeniy Karpov — developer support on early customisation rounds
• Natalia Bogatel — QA and project coordination
• Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)

Agency-side project management, design, and client communication remained with the partner agency throughout. Our team was invisible to the end client. All customisation requests came through the agency’s shared issue backlog; nothing about the build was visible to the end client directly. Each round was closed only after the agency-side reviewer confirmed the changes were resolved to spec.

For agencies with a branded template system