30-Page Dental Template Customisation
30-page dental template customisation shipped in 56 days across 10 templates — 46 hours, 16 tracked tasks, template hardening plus client deployment.
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.
Client (end user): Sunrise Dental Cary — a US general dental practice in Cary, NC
Engagement: White-label template customisation for a US marketing agency
Delivered: April 2025 · 56 days · 46 hours · ~30 URLs · on schedule
The Craft of Template Customisation
30 URLs and 10 agency templates for a new dental practice in Cary, NC — no legacy site, content written from scratch against Google Docs per page. Before client-specific work could begin, template 7 had unfinished shared pages; we completed the missing designs and layouts first, then customised for the practice. That sequence — template hardening before client work — meant the 16-task, 56-day engagement left the agency’s shared template stronger than it arrived.
The value is speed with consistency — but only if the customisation is disciplined. A dev team that “interprets” the Figma, 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 compact, high-frequency template customisation for a new dental practice — an engagement where the template itself needed completion before client customisation could begin.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — General Dentistry |
| End-client | Sunrise Dental Cary (Cary, NC) |
| 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 Figma design on WP Engine) |
| Scope | ~30 URLs — homepage, services lander, service pages, doctor bios, blog, photo gallery, VIP membership, contact, and supporting pages (agency scope reference) |
| Timeline | 56 days (14 Feb – 11 Apr 2025), on schedule |
| Effort | 46 hours — development, QA iterations, and project management |
| Team | 4 specialists |
| Templates | ~10 reusable templates provided by the agency, applied across the site |
| Tech Stack | WordPress · Elementor · WP Engine hosting · Figma-driven per-page design · Site Checker (xaverPRO QA plugin) |
| QA discipline | 16 discrete tasks tracked across the engagement, each closed on agency sign-off |
| Review rounds | ≈2 review rounds across the 56-day calendar window |
| Per-ticket effort | 16 internal Redmine tickets · median 1h / P75 2h per ticket |
The Brief
A US marketing agency delivered us a Figma design for Sunrise Dental Cary and a deployment target on their branded WP Engine-hosted template system. The practice was new — there was no legacy site, no existing content archive, and no prior URL surface to preserve. The agency had already done the upstream work: design audit, client approval, hosting setup, and content sourcing via Google Docs per page. What they needed was a development team that would map the Figma onto the template faithfully and sustain a rapid iteration loop for client edits.
The ask was operational. Take the Figma as the source of truth. Customise the template to match it page by page. Flag findings back into the shared backlog. Return every iteration only after the agency-side reviewer had confirmed the delta was resolved.
What the agency needed to guard against on this engagement was not just customisation drift — it was the compounding risk of building on an incomplete template. The branded template assigned to this project had unfinished pages at kickoff, which meant the team had to complete the template’s shared components before any client-specific work could begin. A dev shop that skips template completion to hit a deadline leaves every future site built on that template inheriting the same gaps. The discipline the agency hired for was completing the shared layer first, then customising cleanly — and that is what the 56-day, 16-task delivery record on this project was built to verify.
Risk context. A new dental practice launching on a branded template with ~30 mapped URLs and no legacy anchor faces a double gap: the template itself may be incomplete, and the client has no pre-existing content to QA against. The risk on this engagement was in the template-completion step — unfinished shared pages had to be designed and built before client customisation could start, and any shortcut in that step would silently propagate to every future practice using the same template. The discipline here was structural: complete the template first, then customise without drift, so the agency’s shared asset was stronger after this project than before it.
How We Did It
1. Template completion before customisation. The agency’s branded template had unfinished pages when the project began. We completed the missing template designs and layouts first — building the shared components the agency would reuse on future sites — before applying any client-specific customisation. We chose this sequence — template completion before client work — rather than building around the gaps, because an incomplete shared layer would propagate design inconsistencies to every future site the agency launches on that template. This meant the effective scope included both template hardening and client customisation, with the template work benefiting every subsequent project on the same template.
2. Figma-as-contract, template-as-canvas. Once the template was complete, the Figma file became the design spec and the branded template the underlying page structure. Our job was to reconcile the two page by page — where the template’s default layout matched the Figma, we kept it; where the Figma required a deviation, we customised. No design decisions originated on our side.
3. QA cycle at template-customisation scale. A clean template customisation is not “build once, review once”. It is “build, QA, adjust, QA, adjust”. Over the course of this project, we tracked 16 discrete tasks in Redmine — each a focused round where the agency flagged design deltas, content edits, or template fixes, which we reviewed, resolved, and returned for confirmation. Tasks ranged from logo placement and service-section formatting to mobile-version updates, doctor-image additions, team-page creation, and client-change implementation. This volume is not a sign of instability; it is the discipline that separates a templated site that looks “roughly right” from one that matches the design.
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 an acceleration.
4. Customisation without drift. Every change we made to the branded template — whether to a page layout, a section component, or a style token — was documented against the Figma reference. 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.
Template 7 arrived incomplete — shared pages unfinished, no client work possible until the shared layer was done. We completed the missing designs and layouts first, then customised for Sunrise Dental without carrying the gap forward. Every site the agency later launched on that template inherited the fix, not the debt.
Operational Integrity at handoff
The agency’s QA review on this engagement caught two staging-build gaps before the client saw the site: the services banner was pulling blog publications from the template default instead of the services list, and a placeholder tab for the second doctor was absent despite the bio slot being ready — both flagged in issue #356 and resolved before client-visible delivery. 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
| Metric | Outcome |
|---|---|
| URLs delivered | ~30 — homepage, services lander, service pages, doctor bios, blog, photo gallery, VIP membership, contact, and supporting pages (agency scope reference) |
| Templates applied | ~10 reusable templates mapped across the site |
| Redmine tasks tracked | 16 discrete tasks logged and closed on agency sign-off |
| Timeline | 56 days, delivered on schedule |
| Effort | 46 hours against a 46-hour estimate — no overrun, no scope creep |
| Team | 4 specialists |
| Hosting handoff | Live on the agency’s WP Engine template environment |
| Page health at handoff | All staging URLs returned HTTP 200 |
The outcome, restated plainly: the agency’s Figma was implemented against their branded template across approximately 30 pages and 10 templates, over 56 calendar days, inside the 46-hour estimate.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | ~3 days | Figma reviewed, template access confirmed, scope agreed |
| Template completion | ~1 week | Missing template pages designed and built |
| Customisation development | ~3 weeks | Page-by-page template customisation to match Figma |
| QA iterations (concurrent) | ~3 weeks | 16 tasks logged; each closed only on agency sign-off |
| Fix rounds | ~1 week | Post-review corrections, mobile updates, client edits |
| Delivery | final day | Site live on WP Engine |
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, Figma-to-layout mapping, and form implementation)
- Anna Polunina — design and layout support (template page completion and client-change implementation)
- Lyudmila Travkina — QA iterations, mobile-version updates, and team-page builds
- 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 task was closed only after the agency-side reviewer confirmed the delta was resolved.
For agencies with a branded template system
If your agency has a branded template and a new-practice Figma but no legacy site to anchor the build — no prior URL structure, content written from scratch — send the Figma and a link to your template. We will estimate the customisation hours and identify any shared-component gaps before kickoff, and return a fixed-hours quote within 24 hours. No cost. No obligation.
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.