21-Page Dental WordPress Build in 31 Days — White-Label Delivery for a US Marketing Agency

The Craft of a Build

21 pages of a dental-practice WordPress build, translated from Figma designs to Elementor through a workbook sitemap whose every row carried its own hour estimate. The scaffold rose before all the content was in — leaving no gap for a less cautious dev partner to collapse the sitemap — and a content-integration tail plus a two-track QA close followed inside 50 hours across 31 days.

Snapshot

The Brief

A US marketing agency retained by Songbird Dental Studio — a general-dental practice in Crawfordville, Florida — handed us a Google Sheets workbook with a full sitemap, Figma designs for homepage and internal pages, a templates catalogue, a launch checklist, and pre-populated SEO and Account Manager issues backlogs. Everything was assembled inside the agency’s WP Engine hosting, with Elementor as the layout tool and Gravity Forms handling the contact and new-patient enquiries.

The ask: build all 21 pages against the agency’s template library, translate the Figma designs into Elementor layouts, integrate the content as it arrived from the client, wire the forms, and work through both QA backlogs until the agency accepted the site. The agency held on to the design direction, the copy, the SEO plan, and every line of contact with the practice.

How We Did It

1. Thirteen templates, 21 pages, one pipeline — built from Figma source design. The site’s 21 pages spread across the agency’s standard template library: Homepage (1), About Us (2 — practice page + doctor bio), Blog Lander (1), Blog (1), Contact Us (1), Services Lander (1), Service Page (8 — teeth whitening, sedation dentistry, dental implants, checkups, veneers, extractions, dentures, cosmetic dentistry, general dentistry, restorative dentistry), Smile Gallery (1), New Patient (1), Technology (1), and Default Template (2 — thank-you page + 404). Before anyone opened Elementor, we’d already pinned each page to the template its sitemap row called for.

2. Figma-to-Elementor structural mapping, not visual tracing. The design we were handed was a live Figma prototype rather than a flat picture. We pinned down its building blocks up front — how headings nested, how sections were spaced, where the mobile breakpoints fell — and held the Figma file as the spec each rendered page was checked against before it cleared staging.

3. The per-row hours we scoped were the contract. We scoped the per-row hours ourselves — 9 hours for the Homepage, 2 for the Services Lander, 0.2 per standard service page, and so on. We shipped each page against the hours its row allowed and never went page-by-page to haggle the price up. When gaps in the client’s copy started to show, we treated those figures as fixed and kept pricing closed — which is exactly what let the agency hold its fixed-cost promise to the practice. Summed across the project, the work landed on the agreed 50 hours.

4. Two QA loops, worked down before launch. Issues were tracked in two agency-side backlog tabs: the SEO Issues Backlog (48 rows, priorities across Low to High) and the AM Issues Backlog (20 rows, flagged with screenshots against staging). Of the 48 SEO items, 40 closed as Completed before launch; 5 were To Do, 1 was a website-live checkpoint, and 1 was In progress. Of the 20 AM items, 19 closed as Completed. The 29-item launch checklist — Design, Functionality, Content, Pre-Migration, Post-Migration — closed behind both backlogs.

The per-row hours we scoped were what held the scope together. When content arrived late and placeholder pages looked like candidates for scope reduction, those row-level budgets were the contract that kept every URL in the build — and the aggregate came in at exactly the agreed 50 hours.

Results

Where it landed: 21 URLs sitting on 13 templates over WP Engine, all of it under the 50 hours we’d quoted. Both QA backlogs — SEO Issues and AM Issues — were taken down to the level the agency would accept, and the launch checklist was closed off before the domain switched over.

Operational Integrity at handoff

Pre-handoff QA on the 21-page staging build caught two categories of issue: the internal QA script flagged page statuses, meta data, links, and heading structure across the sitemap, and a manual image audit surfaced agency-supplied JPGs running 200–500 KB each — batch-converted to WEBP before the performance checklist could close. That pre-handoff pass ran through Site Checker. Our QA approach sets out which categories it covers and the standard each page had to clear. After we delivered, the agency ran the build back through its own setup, parking findings in the shared backlog, and we resolved them until the agency called it done.

Process

Build and QA ran concurrently from the second week; the content-integration stretch began before the last build-phase items had closed — which is why the calendar is 31 days rather than the sum of sequential phases.

Team

Delivery team

• Nikita Tumasevic — developer support on content-integration rounds and issues-backlog corrections
• Pavel Sazhin — QA iterations and fixes
• Anna Polunina — implementation support and QA
• Lyudmila Travkina — lead developer, Figma-to-Elementor mapping and full build across both phases
• Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)

Scheduling the work and speaking to the practice were the agency’s job from first day to last, never ours. Songbird Dental Studio knew the site as their agency’s work; the developers who translated the Figma and closed the backlogs were never named to them. Every QA exchange ran through the shared issue tracker, so the practice met a finished build, not the people or process that produced it.

For agencies commissioning a white-label WordPress build