Dual-Doctor Dental Template Customisation

Client (end user): Marina Pointe Dental — Dr. Alejandro Nieves, DMD and Dr. Bhavya Paranthaman, DMD, Panama City, FL
Engagement: White-label template customisation for a US marketing agency
Delivered: November 2025 – February 2026 · 76 days · 59 hours · on schedule

The Craft of Template Customisation

11 DENTAL-section templates from the agency’s branded library, two Doctor Page instances for separately credentialled practitioners — each customised at the page level while the shared template structure held. The Figma was the contract; the template was the canvas. One early complication: Proxima Nova arrived unlicensed mid-sprint. On Timur’s recommendation the team substituted a visually distinct placeholder so every affected page was immediately obvious in QA when the licensed font landed.

Snapshot

The Brief

A US marketing agency delivered a Figma design for Marina Pointe Dental and a deployment target on their branded Kinsta-hosted template system. The practice presented a specific structural challenge that distinguishes it from the typical single-doctor dental build: two separately credentialled doctors — Dr. Alejandro Nieves, DMD and Dr. Bhavya Paranthaman, DMD — each warranted their own Doctor Page in the template system, under the /about/ path. The agency’s Figma captured both profiles distinctly.

The sitemap was similarly structured in two layers: a launch phase covering the homepage, core services, and information pages marked green in the agency’s workbook, and an “After Release” tier covering sub-service pages, area-we-serve pages, and a Spanish-language service page (/panama-city/servicios-dentales/) deferred to a later phase. Our scope covered only the green-flagged pages; the deferred tier was noted in the workbook but not built during this engagement.

The ask was operational. Take the Figma as the source of truth. Customise the branded template to match it page by page, breakpoint by breakpoint. Route QA findings back through the agency’s shared workspace without anything about the build reaching the end client. Raise concerns — not design decisions — directly to the agency.

One typographic issue emerged early that illustrated the discipline this kind of engagement requires. The agency’s spec called for Proxima Nova as the primary typeface — a licensed font not yet delivered by the client at the time development began. Rather than blocking progress or substituting something visually close enough to be invisible, the team substituted a placeholder typeface with enough visual distance that any page affected by the missing font would be immediately obvious during QA. The correct font was delivered mid-sprint and applied globally via the Elementor global styles system.

How We Did It

1. Figma-as-contract, template-as-canvas. The agency’s Figma file was the design specification. The branded template was 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 at the page level. No design decisions originated on our side.

Two Doctor Page instances were built under /about/meet-dr-alejandro-nieves/ and /about/meet-dr-patricia/ respectively, each customised with the correct photo, credentials, and bio while the shared Doctor Page template structure remained intact. The agency’s Figma captured both profiles; we implemented both against their respective content, ensuring neither page cross-pollinated with the other.

2. QA cycle at template-customisation scale. A clean template customisation is not “build once, review once.” Of the 68 tasks tracked on this project in Redmine, the majority were QA iterations — individual rounds where the agency flagged design deltas, and we reviewed, fixed, and returned the build for another pass. The volume reflects the expected surface area of a Figma-to-template reconciliation, not instability. In this engagement it surfaced issues ranging from layout geometry (broken sections, header alignment, button centring), to form field types, to non-English text found in a page section, to image swap requirements across the two doctor profiles.

The principle behind this is straightforward: on a templated build, the QA loop is where the value is delivered. A shorter QA cycle is a weaker match to the design.

3. Customisation without drift. Every change made to the branded template — whether to a page layout, a section component, or a style token — was contained within per-client page overrides. The agency’s shared template components were not modified. This matters because the agency’s template library spans multiple industries (Dental, Legal, Veterinary, and others visible in the workbook’s template catalog); a drift from one project cannot be permitted to affect another client’s site riding the same template.

The Emergency Dentist page received particular attention during the QA cycle, generating its own tracked issue with multiple fix rounds, after the agency flagged that the page required specific structural treatment distinct from the standard service page layout.

4. Scope management at the sitemap boundary. The agency’s workbook explicitly distinguished “launch phase” pages (green-flagged) from “After Release” pages. We built only the green-flagged pages and kept the deferred tier out of scope. This boundary required active maintenance during QA: when a QA reviewer noted that certain pages had been added to the green-flagged set during the engagement without a corresponding scope discussion, the team flagged it back to the agency for a scope decision rather than absorbing the work silently. The principle is simple: deferred scope is the agency’s call, not the developer’s.

5. Cross-device verification. All customisations were QA’d against Chrome, Firefox, Safari, and Edge on desktop, tablet, and mobile viewports — the standard agency breakpoint set. Each QA round covered the pages affected by the round’s design deltas, maintaining coverage without full-site retesting on every iteration.

The two-doctor build had one structural tension: two practitioners, two paths, one shared template. Customising each Doctor Page at the page level without touching the shared template structure was the discipline that held it. The Proxima Nova placeholder confirmed the approach — Timur’s recommendation to use a visually extreme substitute meant every affected page was immediately obvious in QA, not silently drifting past review.

Results

The outcome, restated plainly: the agency’s Figma was implemented against their branded template across the launch-phase pages, including the dual-doctor profile build, over 76 calendar days, inside the 59-hour estimate.

Operational Integrity at handoff

QA on this build caught two distinct categories of template-residue before handoff: non-English text found on the blog page (agency-flagged in the issue backlog as «Remove this text — it’s not english»), and oversized base64-embedded images in the homepage HTML (~314KB across two inline SVGs) that were causing the screenshot tool to fail and were replaced with optimised PNG and WebP assets. 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 page overrides; the agency’s shared DENTAL template components were not modified.

Customisations stayed in the per-client overrides; the agency’s shared template components were not modified.

Process

Development and QA ran concurrently — characteristic of template-customisation work, where no “QA phase” closes cleanly; the loop runs until the agency signs off.

Team

Delivery team

• Nikita Tumasevic — lead developer (template customisation and Figma-to-layout mapping)
• Anna Polunina — designer and developer support (design coordination, QA rounds)
• Timur Arbaev — QA lead (internal review, fix verification)
• Pavel Sazhin — project management and QA iterations
• 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, with nothing about the build exposed to the end client directly. Each QA round was closed only after the agency-side reviewer confirmed the delta was resolved.

For agencies with a branded template system