59-Page Periodontics Template Customisation in 66 Days — White-Label for a US Marketing Agency
59-page periodontics and dental implants site shipped in 66 days across 10 templates — 54 hours, 41+ QA items, 48-item checklist, AI content throughout.
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
59 pages of a periodontics and dental-implants practice mapped against the agency’s “DENTAL HOMEPAGE DESIGN” Figma prototype, across 10 templates, with AI-generated content replacing the client’s entire existing copy — because the client did not own the rights to migrate it. The agency defined the design reference and sourced the content; we owned the per-page template execution and the QA loop through four review rounds on WP Engine staging.
On a periodontics and dental implants site, this care is more pronounced. A surgical specialty practice carries a service taxonomy that a general-dental template was not originally built around: laser procedures, bone grafting, scaling and root planing, crown lengthening, and full-arch implant reconstructions are not the same content structures as routine cleanings or fillings. The agency also made an unusual call here: rather than migrating the client’s existing copy, they commissioned new AI-generated content for the entire site. Every page was a net-new content placement — Figma as design reference, fresh copy as content, template as the structural container.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — Periodontics and Dental Implants |
| End-client | Middlesex Periodontics & Dental Implants (East Brunswick, NJ) |
| Engagement | White-label template customisation for a US marketing agency specialising in local-business websites |
| Project Type | WordPress template customisation (agency’s branded dental template + per-page Figma design on WP Engine) |
| Scope | 59 URLs — homepage, 24 service pages (laser procedures, periodontal procedures, dental implants, bone grafting, plus supporting specialty pages), 3 about-us pages, 1 doctor page, 1 contact page, 28 patient-information and supporting pages |
| Timeline | 66 days (19 Feb – 26 Apr 2025), on schedule |
| Effort | 54 hours — 32h dev · 14h QA and fix rounds · 8h PM |
| Team | 6 specialists |
| Templates | 10 reusable templates provided by the agency, applied across the 59 pages |
| Tech Stack | WordPress · Elementor Pro · Gravity Forms · WP Engine hosting · Yoast · Site Checker (xaverPRO QA plugin) |
| QA discipline | 41+ tracked issues reconciled in the agency’s issues backlog across a 48-item launch checklist |
| Engagement cadence | 41 agency-raised issues · all closed by handoff (12-day active span, 2025-03-21 – 2025-04-01) |
| Review rounds | ≈4 review rounds across the 66-day calendar window |
| Launch checklist | 48 items, signed off before cutover |
The Brief
Middlesex Periodontics & Dental Implants is a periodontics specialty practice in East Brunswick, New Jersey, led by Dr. Daniel Reich. The practice covers periodontal surgery, dental implants, laser procedures, and full-arch restoration — a clinical scope that extends well beyond a general dentistry service menu. A US marketing agency was managing the site redesign: they owned the design (a Figma prototype for the homepage plus inner-page templates), the content strategy (AI-generated content because the client had no rights to copy their existing site), the WP Engine hosting setup, and the client relationship. Our scope was to customise the agency’s dental template system to the Figma design and populate every page with the new content.
The workbook was structured across 65 sitemap rows, 4 of which were redirects and 2 were deletions, leaving 59 active pages to build against 10 templates. The ask: replicate the revised “Dental Homepage Design” Figma prototype on the homepage and inner-page templates, integrate the AI-generated content throughout, fix the form and navigation issues that surfaced during the agency’s review cycle, and close the issues backlog before the site moved to production. Design, content approval, client communication, and SEO strategy all stayed upstream with the agency.
Risk Context — The challenge on a full-content-replacement template customisation is that every page is placeable by content and design reference, but nothing can be cross-checked against a live source. With a typical Templated project, the team can compare the live site against the staging build to catch mis-placed copy or wrong imagery; here the content was net-new and the design existed only in Figma. A customisation that placed content on the wrong template section — or applied the correct layout but missed the client-specific images and contact details the agency provided — would not fail visibly on staging. The agency’s QA cycle, and our fix rounds, were the only gate.
How We Did It
1. Figma-as-contract, template-as-canvas. The Figma prototype fixed the homepage design and set the CSS reference every inner page inherited — colours, fonts, text sizing, background treatment, navigation bar, and footer structure. The agency’s branded dental template held all of that as its structural shell. We worked between the two: defaults that already agreed with the Figma stayed, and anywhere the prototype demanded a departure, we built it. The design intent was never ours to set. When the Figma became temporarily inaccessible during the engagement (a platform availability issue), the team secured a local export to maintain build continuity without introducing gaps.
2. QA cycle at specialty-dental scale. A customisation comes out clean in rounds, not on the first pass. Across this project we tracked 14 tasks in Redmine and worked through 41+ items in the agency’s issues backlog — raised and put right across navigation structure, hero-section layout, testimonials population, contact-form routing, image swaps, content placement, and link integrity. Each of those items marked the distance between “template applied” and “template matched to Figma and client content,” and closing them is the difference between a templated site that reads about right at a glance and one that survives the agency’s review.
3. Specialty vocabulary across 10 templates. The practice’s service taxonomy spans periodontal surgery, dental implants, laser procedures (LANAP, LAPIP), bone grafting, and patient-information sub-sections for financing, insurance, and forms. The agency’s template library included 10 templates for the engagement: Homepage, About Us (used 3 times across the practice’s story, the team, and the staff pages), Doctor Page, Service Page (24 times — the heaviest template on this project), Contact Us, Default Template (28 supporting pages), plus the agency’s Smile Gallery template for the client-supplied before-and-after imagery. The sitemap row dictated which template a page got, and nothing was assembled off to the side of that system.
4. Cross-device verification. We ran the customisations through Chrome, Firefox, Safari, and Edge on desktop, tablet, and mobile viewports. A round looked only at the pages its own adjustments had moved instead of re-running the entire site, which kept the cycle tight while still covering every breakpoint in scope.
Treating the Figma as the contract was what held the build together when the Figma platform became temporarily inaccessible mid-engagement. The team exported a local copy rather than pause, and the build continued against that reference — four review rounds and 41 backlog items later, the agency signed off on a site that matched what the Figma had specified from the start.
Operational Integrity at handoff
The issues backlog ran 41 items over a 12-day review window — URL integrity (404s and unclickable phone and address links), mobile contrast (menu text invisible against the background), and content placement (FAQ answers duplicated across all homepage entries) — each caught before the build reached the agency. That sweep went through Site Checker. Our QA approach sets out the categories and why a build never changes hands with a check open. After handoff the agency reviewed it on their own tools, feeding findings into the shared backlog for our fix loop until sign-off.
Every change sat inside the per-client overrides, never the agency’s shared template components.
Results
| Metric | Outcome |
|---|---|
| URLs delivered | 59 — Service Page (24) · Default Template (28) · About Us (3) · Homepage (1) · Doctor Page (1) · Contact Us (1) · Redirect-handled (4 handled per sitemap, not built as pages) |
| Templates applied | 10 of 10 reusable templates from the agency’s library |
| Launch checklist | 48 items signed off |
| Issues backlog | 38 / 41 closed as Completed; 3 in QA at handoff |
| Redmine QA iterations | 14 of 14 tasks tracked, all closed or signed off |
| Timeline | 66 days (19 Feb – 26 Apr 2025), delivered on schedule |
| Effort | 54 hours against a ~54-hour estimate — no overrun |
| Team | 6 specialists |
| Hosting handoff | Live on WP Engine; production at eastbrunswickperio.com |
| Site status | Live at https://www.eastbrunswickperio.com/ — verified April 2026. |
Boiled down: the agency’s Figma went onto their branded dental template over 59 pages and 10 templates, across 66 calendar days, and stayed inside the estimated hours. The issues backlog — which traces the distance from first pass to finished state — sat at 38/41 items Completed by the time the site reached production.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | ~1 week | Figma accessed, AI content workbook reviewed, template access confirmed, scope and hours agreed |
| Initial customisation development | ~3 weeks | Page-by-page template application, homepage design replicated to Figma spec, AI content integrated |
| QA iterations (concurrent) | ~4 weeks | Issues backlog opened; 14 Redmine tasks tracked; image swaps, navigation, form routing, and layout corrections applied round by round |
| Content and client-change integration | ~2 weeks (in parallel) | Client-supplied images and text corrections absorbed without template drift |
| Delivery | final day | Site live on WP Engine at eastbrunswickperio.com, HTTP 200 confirmed |
Building and QA went on side by side the whole way — par for the course on template-customisation work, where the agency’s review cycle keeps opening fresh backlog items as older ones get cleared. The 66-day calendar is the sum of those overlapping passes, not a chain of separate phases.
Team
Delivery team
- Nikita Tumasevic — lead developer (template customisation and Figma-to-layout mapping)
- Pavel Sazhin — project management and QA iterations
- Anna Polunina — QA iterations, client-change integration, and fix rounds
- Lyudmila Travkina — content updates, navigation and form corrections
- Natalia Bogatel — QA and project coordination
- Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)
Project management, design, content approval, and client communication all stayed with the partner agency from beginning to end. Dr. Reich’s practice spoke only to the agency it had retained; our six specialists lived entirely in Redmine tasks and the shared issue backlog, with no channel to the practice and no name on anything that reached it. A round closed only once the agency-side reviewer had signed it off.
For agencies with a branded template system
A branded template system for a periodontal practice introduces structural risk for the agency that commissions it. For this practice — a single-surgeon implant practice with diagnostic staging; for others — a multi-location dental group with general care. Child-theme overrides will break on the first template vendor update. Brand-system tokens will propagate inconsistently, leaving old colors on archive pages. The client’s editors will discover that specialty procedure blocks are hidden from the library, stalling content production.
The question to ask a dev partner is not “can you use the template?” — it is “how will you ensure the client’s customizations survive the next template update?”
Send us the template source or template ID and your brand spec. We will map your customizations against the template core and pinpoint where the next vendor update will fight them. Then we 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.