30-Page Dental Template Customisation in 56 Days — White-Label for a US Marketing Agency
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.
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 appeal of a template is that it ships fast and stays consistent across an agency’s roster. That only holds while whoever customises it keeps a tight hand. Hand the work to a team that treats the Figma as open to interpretation, drops review passes to save time, or wanders off the template’s design rules, and the agency would have been better off commissioning a one-off site from zero.
The 16-task delivery record below is 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 |
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. Everything ahead of the build was already settled on the agency’s side: the design had been audited, the client had signed off, hosting was provisioned, and each page’s copy was waiting in its own Google Doc. The gap they were filling was a build team that could lay the Figma onto the template without distorting it and keep turning client edits around quickly as they came in.
What they handed us was an operational brief, not a creative one. Treat the Figma as the thing to match. Bring the template into line with it page by page. Push anything we noticed back into the shared backlog. And send each pass back only after their reviewer had confirmed the delta was closed.
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. What 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 fix 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. With the shared layer finished, the work settled into matching two things to each other: the Figma carried the design spec, the branded template carried the structure beneath it. We reconciled them a page at a time, holding the template’s default layout wherever it already met the Figma and customising only at the points where the design asked for something else. None of those calls were ours to make; the design direction came entirely from the agency.
3. QA cycle at template-customisation scale. Customising a template well is never a single build followed by a single look-over. The rhythm is build, check, fix, check again, fix again, and it keeps repeating. Across this engagement that rhythm logged as 16 discrete tasks in Redmine, each one a tight round in which the agency raised a design delta, a content edit, or a template fix, and we worked it, closed it, and sent it back for confirmation. The list ran from logo placement and service-section formatting through mobile-version updates, doctor-image additions, a new team page, and a wave of client changes. A count like that does not signal a wobbly build; it is exactly the difference between a templated site that reads as “close enough” and one that actually lands on the design.
It comes down to where the value sits: on a templated build, it sits in the QA loop. Cut that loop short and you have not delivered faster. You have delivered something that matches the design less well.
4. Customisation without drift. Whatever we altered on the branded template, whether a page layout, a section component, or a style token, got recorded against the Figma it traced back to. Nothing we did seeped down into the template’s shared components, so when the agency built its next site on the same base, it inherited the template intact rather than the marks of this project.
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 caught two staging-build gaps before the client saw the site: the services banner pulled blog posts instead of the services list, and a placeholder tab for the second doctor was missing though the bio slot was ready — both flagged and resolved before delivery. Before any of it reached the agency, it cleared Site Checker. Our QA approach sets out the categories and the rule that no finding ships open. After handoff the agency ran its own checks and dropped findings into the shared backlog, which we cleared until they called it done.
Whatever we customised stayed in the per-client overrides. We left shared components untouched.
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 |
Boiled down: the agency’s Figma went live on their branded template across roughly 30 pages and 10 templates, the calendar ran to 56 days, and the hours stopped at the 46 we had estimated.
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 |
There was never a clean line between developing and reviewing here. On template-customisation work the two overlap by nature. No review phase ever shuts neatly; the loop just keeps turning until the agency calls it signed 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)
Project management, design, and every conversation with the client stayed in the agency’s hands from start to finish. To Sunrise Dental Cary, the agency was the web partner; the practice never had reason to know a separate build team existed, and keeping it that way was the whole arrangement. Customisation requests reached us as entries in the agency’s shared backlog, and no task came off that list until their reviewer had confirmed the delta was resolved.
For agencies with a branded template system
On a branded template, the shared asset is the foundation. For this practice — a single dental office launching on a scalable template; for others — a multi-location group depending on the same template for consistency across sites. The risks are quiet: colour updates stop propagating when the client edits the customizer, child-theme overrides break on the next template update, and the editor experience fails for non-developer staff adding a simple procedure page.
The useful question to put to a dev partner isn’t whether they can work on your template. It’s how they’ll fence off the client overrides so the shared template still stands after the next update lands on it.
Send us the template source or template ID and your brand spec. We will trace the customization layers, flag any overrides that will break on the next release, 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.