26-Page Dental Template Customisation in 82 Days — White-Label for a US Marketing Agency
A 26-page dental template customisation across 5 templates — 24 hours, 82 days, 93+ QA items reconciled against a 29-item launch checklist.
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
26 pages of Floss Lincoln Park built in two acts: a template scaffold deployed first, then a re-estimate when branding and copy arrived 17 days later. Phase 1 set the architecture; Phase 2 integrated content that had been written without reference to the template’s section structure. The 82-day span, 5 templates, and 93 QA items reflect what it takes to reconcile an independently-authored content brief against a live template without drift.
A template buys you pace without sacrificing consistency, and the catch is that the pace only holds if the customisation work stays disciplined. Hand it to a team that treats the design as a suggestion, trims the QA rounds, or wanders off the template’s design system, and the agency would have been better off with a blank canvas.
Two acts: scaffold before content existed, re-estimated and populated once branding and copy arrived.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — General Dentistry |
| End-client | Floss Lincoln Park (US dental practice) |
| Engagement | White-label template customisation for a US marketing agency specialising in local-business websites |
| Project Type | WordPress template customisation (agency’s branded template on WP Engine) |
| Scope | 26 URLs — homepage, insurance, payment policy, patient forms, new patients, contact, meet the doctors, and 18 service pages |
| Timeline | 82 days (28 Mar – 18 Jun 2025), on schedule |
| Effort | 24 hours — development, QA iterations, and project management |
| Team | 3 specialists |
| Templates | 5 reusable templates provided by the agency, all applied across the 26 pages |
| Tech Stack | WordPress · Elementor · WP Engine hosting · Site Checker (xaverPRO QA plugin) |
| QA discipline | 93+ tracked SEO + AM issues reconciled in the agency’s backlog across a 29-item launch checklist |
| Engagement cadence | 64 agency-raised issues · all closed by handoff (5-day active span, 2025-04-25 – 2025-04-29) |
| Review rounds | ≈4 review rounds across the 82-day calendar window |
| Launch checklist | 29 items, signed off before cutover |
The Brief
A US marketing agency delivered us a template customisation brief for Floss Lincoln Park — a new dental practice starting from scratch. The agency was still working on the client’s branding and logo when development began, and website content would be delivered mid-build. The initial scope was to set up the template scaffold; a second phase would populate pages once content arrived.
The ask was sequential in a way that a fixed-scope rebuild is not. Build the template bones first. Wait for content. Re-estimate. Populate pages. Run QA. The 26-page scope was the entry point. The real work was in preserving template integrity while integrating branding and copy that did not exist when we made the first commit. A limitation of the sitemap-driven estimate was that the design files included sections — such as the blog — that had no row in the initial workbook scope, so their templates fell outside the original per-page budget.
What the agency needed to guard against here was a dev shop that equates “template copied” with “done.” On a templated engagement for a new practice — where the client has no live site to regression-check against and no content baseline to verify against — the build is only complete when every page is accurate, every placeholder is stripped, and every QA item has been reconciled. Down tools the moment the template looks roughly right, and the agency inherits a QA backlog that is now theirs to clear. Read the 93-item backlog on this project the other way round: not evidence of rework, but the running tally of findings we drove down to nothing.
Risk context. A template customisation for a greenfield practice runs in two acts: scaffold first, content second. The risk is not in the initial template copy — it is in what happens when branding, copy, and a colour guide arrive after the scaffold is already live. A dev team that simply pastes content into placeholder slots can silently break template components, drift from the design system, or leave orphaned pages that were created for the scaffold but never populated. What kept this project sound was re-estimating the scope when content arrived, integrating every piece without template drift, and reconciling the full issue backlog before handoff.
How We Did It
1. Figma-as-contract, template-as-canvas. The agency’s design direction and branded template set the truth we worked against. We squared one with the other on a page-by-page basis: wherever the template’s stock layout already lined up with the design, it stood; wherever the design called for something the template didn’t do out of the box, we customised to close the gap. None of those calls were ours to make from scratch.
2. QA cycle at template-customisation scale. Getting a template customisation clean does not happen in a single build-then-review pass. It runs in a loop — build, QA, adjust, QA, adjust — and keeps cycling. Of the 11 tasks tracked on this project, 3 were QA iterations — individual rounds where the agency flagged design deltas, we reviewed, fixed, and returned the build for another review. Behind those rounds was a much larger reconciliation: the agency tracked 93+ items across two issue-backlog tabs (65 SEO findings and 28 AM findings), all of which were reviewed and addressed through the shared fix loop.
Here is what that comes down to on a templated build: the QA loop is the part that actually earns the fee. Cut the cycle short and you don’t ship sooner — you ship something that sits further from the design.
3. Customisation without drift. Whenever we touched the branded template — a page layout here, a section component there, a style token somewhere else — the edit was logged against the design reference so it could be traced back. And none of it bled into the agency’s shared template components; the work we did for Floss Lincoln Park left every other site running on that same template untouched.
4. Cross-device verification. Every customisation got walked through Chrome, Firefox, Safari, and Edge at the desktop, tablet, and mobile viewports the agency uses as its standard breakpoint set. A given QA round only looked at the pages that round’s design deltas had touched, never the entire site — that scoping is what lets a templated build move quickly while still covering everything that changed. We scoped the build by the workbook sitemap row budget rather than by the full design-file count — unplanned pages were surfaced as separate tasks because the sitemap was the closed-scope contract between the agency and the build team.
The constraint of content arriving after the scaffold was already built forced a specific sequence: set the template bones to a 4-hour estimate, wait for the agency’s content brief, re-estimate at 11 hours when it arrived. That ordering was the point — integrating branding and copy into a live scaffold without drifting the template costs more when the content was written without reference to the template’s section structure.
Operational Integrity at handoff
Three findings ran the fix loop: duplicate meta-description tags (Rank Math emitting one, an Elementor global setting a second) collapsed to one; four Rank Math sitemaps (pages, blog, services, doctors/FAQ) condensed to the two the agency required; and 404s from slug cleanup — every page that lost its -info suffix got a 301 before go-live. Our last gate was Site Checker (our QA approach: categories plus the no-open-finding rule). The agency then reviewed on its own tooling, feeding what it found to the shared backlog for us to clear.
Every edit lived inside the per-client overrides. We left the agency’s shared template components untouched.
Results
| Metric | Outcome |
|---|---|
| URLs delivered | 26 — 1 homepage, 18 service pages, 1 about, 1 contact, 1 new patients, 1 patient forms, 1 insurance, 1 payment policy, and 1 blog |
| Templates applied | 5 of 5 reusable templates built and mapped across the 26 pages (Homepage, Default Template, About Us, Service Page, Blog) |
| Launch checklist | 29 items signed off |
| QA / SEO + AM issues tracked + resolved | 93+ items reconciled across the agency’s two issue-backlog tabs (65 SEO + 28 AM) |
| Redmine QA iterations | 3 of 11 tasks (27%) tracked at the iteration level |
| Timeline | 82 days, delivered on schedule |
| Effort | 24 hours against a 24-hour estimate — no overrun, no scope creep |
| Team | 3 specialists |
| Hosting handoff | Live on the agency’s WP Engine template environment |
| Page health at handoff | 26 / 26 staging URLs returned HTTP 200 in the sitemap audit |
In sum: the agency’s template was customised across 26 pages and 5 templates, over 82 calendar days, inside the 24-hour estimate.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | ~3 days | Template reviewed, scope agreed, scaffold build planned |
| Scaffold development | ~2 weeks | Template bones built before content existed |
| Content integration & re-estimation | ~4 weeks | Re-estimated at 11 hours when content arrived; pages populated |
| QA iterations (concurrent) | ~4 weeks | 3 QA rounds logged; 93+ backlog items reconciled |
| Delivery | final day | Site live on WP Engine |
Build and QA overlapped rather than queueing, which is how template-customisation work tends to go: there is no tidy “QA phase” that clicks shut, just a loop that keeps turning right up until the agency signs off.
Team
Delivery team
- Nikita Tumasevic — lead developer (template customisation and content integration)
- Anna Polunina — developer (re-estimation and content-phase support)
- Pavel Sazhin — QA iterations and fixes
- Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)
The end-client relationship sat with the agency from start to finish. Customisation requests came to us down the agency’s shared backlog, never straight from the practice — to Floss Lincoln Park the agency was the one and only vendor, and there was nothing to tip them off that our team was in the mix. No iteration went out the door until the agency-side reviewer had confirmed its changes were resolved to spec.
For agencies with a branded template system
A branded template system keeps the scaffold separate from the practice’s brand layer. For this practice — a single-location dental group with a custom brand system; for others — a multi-location DSO enforcing strict brand consistency across dozens of sites. The quiet failures: a theme update from the vendor silently overwrites the brand customizations the agency’s client approved. Brand tokens stop propagating the first time a colour changes in the customizer. Editors find template blocks hidden when the system was built for developers, not content staff.
Before you commit, the thing worth pressing a dev partner on isn’t whether they can stand the template up. It’s how they pin down the brand tokens so the next vendor update doesn’t quietly reset them.
Send us the template source or template ID and your brand spec. We will walk the token configuration against your brand guidelines, highlight the override points a standard update will overwrite, and return a fixed-hours quote. Free review, fixed quote in hours.
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.