33-Page Dental + Tongue-Tie Template Customisation

Client (end user): Charleston Dental and Tongue Tie — a US dental practice with a tongue-tie and lip-tie specialty
Engagement: White-label template customisation for a US marketing agency
Delivered: September 2025 · 94 days · 57 hours · 33 URLs · on schedule

The Craft of Template Customisation

33 pages of a dental template customisation against a per-page Figma — a practice combining general dentistry with a tongue-tie procedure section, both running on the agency’s 10-template Kinsta set. Fifteen general dental service pages and 4 age-stratified procedure sub-pages share the same Service Page template but carry different content shapes; treating the procedure section as a variant of the dental services would not fail QA — it would register as a content problem after launch.

Snapshot

The Brief

A US marketing agency delivered us the Figma design for Charleston Dental and Tongue Tie and a deployment target on their branded Kinsta-hosted template system. The practice offers both general dental care and a specialist tongue-tie and lip-tie procedure service — a combination that is less common than a general dentistry site and that created a dual content structure the agency needed mapped into the template correctly. The upstream work was the agency’s: design, client approval, content planning, and hosting. Our job was to make the Figma real on their template.

The operational ask was clear: take the Figma as the source of truth, customise each page to match it, and return the site only after every design delta was signed off in the agency’s shared workspace. Alongside the main build, the scope included a blog page, a blog post about frenectomy, a meet-the-doctors sub-page, and a round of content-and-image updates that extended the engagement into September.

What the agency needed to guard against here was a structural problem specific to this practice’s service offering. A tongue-tie specialty section is not a second tab on a services lander — it has its own landing page and age-stratified sub-pages (infants, toddlers and older children, adults), each with content distinct from the general dental services nearby. The risk in a templated build is that the shared Service Page template treats all of these the same: a developer relying on template defaults could produce pages that match the Figma visually on the homepage but silently flatten the procedure section’s distinct content hierarchy into the same layout as a teeth-cleaning page. The agency hired for discipline, not just output. The customisation had to honour the structural difference between general dental services and the procedure section — using the same template set without collapsing the content distinction between them.

How We Did It

1. Figma-as-contract, template-as-canvas. The Figma was the source of truth throughout. The branded template was the canvas. For every one of the 33 pages, the question was: does this page’s Figma frame match the template default, or does it require a per-page customisation? Where the template fit, we kept it. Where the Figma required a deviation, we customised — including the tongue-tie procedure landing page, which sits structurally between a services lander and a service page and needed its own layout treatment within the Service Page template’s parameters.

2. Two service sections, one template set. The site carries 15 general dental service pages alongside 4 tongue-tie and lip-tie procedure pages. All 19 live under the same Service Page template. The work of keeping them distinct was editorial and structural: the general dental pages follow the agency’s standard service-page pattern; the procedure pages carry age-stratified sub-pages (infants, toddlers and older children, adults) with content blocks and anchor-link navigation built on the same template but adapted to a different content shape. Getting this right required treating the procedure section not as a variant of the dental services section but as a separate content architecture that shares the template layer.

3. QA cycle at template-customisation scale. A clean template customisation is not “build once, review once”. The project accumulated 120+ line items in the agency’s issue-backlog workspace — individual QA rounds where the agency flagged design deltas, we reviewed, fixed, and returned the build. Notable within this loop: the hero-section treatment (all hero sections in the Figma render as black-and-white gradient overlays; the template’s default did not match; the fix was a CSS overlay blending approach), the anchor-link routing fix on the homepage reviews section (the link required a full absolute URL including page path plus anchor, not just a fragment), and the iterative image sizing passes that followed the team’s content and images task. Each pass added precision; none rewound earlier work.

4. Customisation without drift. Every change was scoped to the per-client implementation. At no point were the agency’s shared template components modified. The tongue-tie procedure section’s adaptations lived in per-page Elementor overrides, not in the template’s shared layer. The next site that runs on this template has no awareness that 33 pages of custom implementation passed through it.

5. Cross-device verification. Customisations were checked at desktop, tablet, and mobile viewports. The image-sizing and hero-overlay work from the QA loop is inherently multi-resolution — every layout change triggered a cross-device re-check before the round was closed. The QA pass on the final content-update task (issue #966) included a site-wide content change verification pass that ran across all affected pages before handoff.

An ongoing limitation during QA was that the practice had no professional team portraits available — the home page team block and the meet-the-team page were built without original photography, using placeholder silhouettes until the agency sourced images or opted to omit team photos from those sections entirely. We chose per-page Elementor overrides over template-layer modifications because altering the shared template would carry tongue-tie-specific customisations — age-stratified sub-page navigation, procedure-specific content blocks — into every future site the agency deploys on this template, which the next client did not request and should not inherit.

The structural tension was that a tongue-tie procedure section is not a dental services variant — its age-stratified sub-pages carry a different content purpose, and collapsing them into the same template pattern would not fail QA; it would register as a content problem after launch. The resolution was a separate content architecture within the same template, using per-page Elementor overrides that left the agency’s shared layer unchanged.

Operational Integrity at handoff

Two QA findings shaped the pre-handoff load: every hero section required a CSS gradient-overlay fix to match the Figma black-and-white treatment — a template default that did not apply the colour-mode overlay — and the homepage reviews anchor was initially a bare fragment (#reviews) where the correct form was the full absolute URL including page path, caught before the agency reviewed the build. 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

The outcome, restated plainly: the agency’s Figma was implemented against their branded template across 33 pages and 10 templates — including a specialist procedure section that required structural distinction within a shared template — over 94 calendar days, inside the 57-hour estimate.

Process

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, content rounds)
• Anna Polunina — project coordination (content management, task progression, agency liaison)
• Pavel Sazhin — QA iterations and fixes
• Timur Arbaev — QA support and final contact-details pass
• 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 operated as the agency’s invisible build partner. All customisation requests arrived through the agency’s shared workspace; nothing about the build was exposed to the end client directly. Each QA round closed only when the agency-side reviewer confirmed the delta was resolved.

For agencies with a branded template system