99-Page Dental Template Customisation in 60 Days — White-Label for a US Marketing Agency
99-page dental practice site customised across 10 templates and a 49-item checklist in 60 days — 61 hours, 9 QA items resolved, shipped on schedule.
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
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 49-item checklist could close.
What you buy with a template is fast delivery that still looks consistent — and that only holds when the customisation keeps discipline. Hand the job to a team that reads its own intent into the design, trims the QA rounds, or wanders off the template’s design system, and you’d have been better off building from nothing.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — General Dentistry |
| End-client | Grand Oaks Dentistry (US dental practice, Austin, TX) |
| Engagement | White-label template customisation for a US marketing agency specialising in local-business websites |
| Project Type | WordPress template customisation (agency’s branded template + per-page design on WP Engine) |
| Scope | 99 URLs — homepage, services lander, service pages, doctor bio, staff, testimonials, insurance/financing, blog posts, and supporting pages |
| Timeline | 60 days (6 Feb – 7 Apr 2025), on schedule |
| Effort | 61 hours — development, QA iterations, fixes, and project management |
| Team | 6 specialists |
| Templates | 10 reusable templates provided by the agency, applied across the 99 pages |
| Tech Stack | WordPress · Elementor · WP Engine hosting · Figma-driven per-page design · Site Checker (xaverPRO QA plugin) |
| QA tracking | 9 tracked issues reconciled in the agency’s backlog across a 49-item launch checklist |
| Engagement cadence | 9 agency-raised issues · all closed by handoff |
| Review rounds | ≈4 review rounds across the 60-day calendar window |
| Launch checklist | 49 items, signed off before cutover |
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. All the groundwork sat behind them already — client requirements gathered, template chosen, hosting stood up, content sourced. The gap they were filling was a build team that would carry the migration through without distortion and stay in the QA loop for as many rounds as the design match demanded.
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.
Risk context. A template migration that moves content faithfully but loses the design system in transit delivers a site that is functionally complete and visually wrong. The failure mode is aesthetic, not functional — pages load, links work, content is present — but the spacing, typography hierarchy, and colour discipline that made the template worth buying are diluted. The agency was guarding against a dev team that treats template customisation as content transport rather than design-system execution.
How We Did It
1. Figma-as-contract, template-as-canvas. Two things governed what we built: the agency’s Figma references and the branded template itself. We squared one against the other across the page set — if the template shipped a default layout that already honoured the design, it stayed; if the legacy content forced a departure, we customised to suit. Not one design call started with us.
2. QA cycle at template-customisation scale. Customise a template well and you don’t get one build followed by one review. You get a build, then check, then correct, then check and correct again. Here that loop opened with 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 went to production before all staging updates had closed. We tracked each round as a separate Redmine task and closed it only on agency sign-off.
On templated work, that loop is the part that actually earns its keep. Cut it short and you don’t ship sooner — you ship something that sits further from the design.
3. Customisation without drift. Anything we touched on the branded template — a page layout, a section component, a style token — lived inside the per-client override layer and nowhere else. None of it reached the template’s shared components, so the work done for Grand Oaks left the template intact for whatever site the agency pointed it at next.
4. Cross-device verification. Each customisation got checked in Chrome, Firefox, Safari, and Edge, and at desktop, tablet, and mobile widths. A round only re-tested the pages its own design deltas had touched rather than the full site — the way a templated build holds its pace while still covering what changed.
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 — before the first handoff. When the agency flagged drift from the template’s visual promise, a second pass re-ran the checks on the revised pages before they saw the corrected build. That pass went through Site Checker. Our QA approach sets out the categories and the zero-defect bar. After we handed off, the agency ran its own review and logged findings into the shared backlog, feeding our fix loop to sign-off.
Every customisation sat in the per-client override layer, and the agency’s shared template components were left untouched.
Results
| Metric | Outcome |
|---|---|
| URLs delivered | 99 — homepage, services lander, service pages, doctor bio, staff, testimonials, insurance/financing, blog posts, and supporting pages |
| Templates applied | 10 of 10 reusable templates built and mapped across the 99 pages (Homepage, Services Lander, Service Page, About Us, Doctor Page, Contact Us, Blog Lander, Blog, Smile Gallery, Default Template) |
| Launch checklist | 49 items signed off |
| QA / SEO issues tracked + resolved | 9 items reconciled across the agency’s issue-backlog tab |
| Redmine QA iterations | 5 of 13 tasks tracked at the iteration level (QA stage, client revisions, backlog fixes, testimonials update, live-site cleanup) |
| Timeline | 60 days, delivered on schedule |
| Effort | 61 hours — no overrun, no scope creep |
| Team | 6 specialists |
| Hosting handoff | Live on the agency’s WP Engine template environment |
| Page health at handoff | Staging URLs returned HTTP 200 in the sitemap audit |
What shipped: the agency’s template, customised across 99 pages and 10 templates, over 60 calendar days, all of it inside the 61-hour estimate.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | ~1 week | Figma reviewed, template access confirmed, scope agreed (45-hour estimate) |
| Customisation development | ~2 weeks | Page-by-page content migration and template customisation |
| QA iterations (concurrent) | ~2 weeks | QA stage + client revision round to restore template feel |
| Fix rounds | ~3 weeks | Post-live corrections, meta-data comparison, redirect fixes, urgent cleanup |
| Delivery | final day | Site live on WP Engine |
Build and QA overlapped from the start, as they tend to on customisation work: there’s no tidy “QA phase” that shuts behind you, just a loop that keeps turning until the agency calls it done.
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)
Project management, design, and every word to the client stayed with the partner agency from first day to last. Grand Oaks Dentistry dealt with the agency and the agency alone: the staging review, the “looks unprofessional” note, and the sign-off all moved through the agency, and our customisation work surfaced to the practice under the agency’s brand. Change requests came to us one route only — the agency’s shared issue backlog. A round shut only once the agency-side reviewer had confirmed the fix matched the spec.
For agencies with a branded template system
A branded template is a design system, not a theme. The agency invests in it, and the developer must protect that investment. For this practice—cosmetic and restorative; for others—paediatric or a multi-location DSO. The concrete risks: the next parent-template update will break your child-theme overrides. Brand tokens set in the customizer will cascade poorly into hardcoded fallbacks. The ACF schema will drift between the template core and your customisations, leaving the editor interface broken for your client’s staff.
The question to ask a dev partner is not “can you build on a branded template?” — it is “how exactly will you scope my client-layer overrides so they survive the next template update?”
Send us the template source or template ID and your brand guide. We will map the customisation layer against the parent schema, document where the next update will break your overrides, and return a fixed-hours quote. No charge for the review; the quote comes back in hours, not a range.
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.