Las Vegas Dental Rebuild — Shutdown Deadline
A Las Vegas dental rebuild under a shutdown deadline — 44.2 hours, 20 days. Duplicate metadata corrected, library section scoped out, redirects verified.
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.
Client (end user): Amazing Smiles Dentistry — Las Vegas, NV
Engagement: White-label development for a US marketing agency
Delivered: May 2025 · 20 days · 44.2 hours · on schedule, no overrun
The Craft of a Rebuild
A 20-day rebuild under a firm platform-shutdown deadline — the practice’s dental managed-hosting platform was decommissioning on 1 June 2025, with no extension available. We held the 44.2-hour estimate, scoped out the library section per agency instruction, corrected duplicate metadata carried from the legacy platform, and handed off to the agency’s QA window before the shutdown date.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — General Dentistry |
| End-client | Amazing Smiles Dentistry (Las Vegas, NV) |
| Engagement | White-label WordPress build for a US marketing agency specialising in local-business websites |
| Project Type | WordPress rebuild from a dental managed-hosting platform to WordPress + Elementor Pro on WP Engine |
| Scope | Full site — services, doctor and team pages, library section scoped out, contact forms, meta implementation |
| Timeline | 20 days (30 Apr – 20 May 2025), on schedule with hard external deadline |
| Effort | 44 hours against a 44.2-hour estimate — no overrun |
| Team | 4 specialists (dev · QA · content · PM) |
| Tech Stack | WordPress · Elementor Pro · Gravity Forms · WP Engine · Rank Math Pro · Screaming Frog · Site Checker (xaverPRO QA plugin) |
| Content parity check | Original-vs-rebuild content diff cleared before handoff — no missing copy, no broken internal links, no structural drift |
| Delivered | Spec followed line-for-line — redirects, meta titles, scope boundary enforced on library section, 44-hour estimate held |
| Review rounds | ≈3 review rounds across the 20-day calendar window |
| Per-ticket effort | 5 internal Redmine tickets · median 10h / P75 44.2h per ticket |
The Brief
Amazing Smiles Dentistry was hosted on a dental managed-hosting platform whose service was being discontinued. The agency had a firm date — the platform’s shutdown — and needed the full WordPress rebuild complete and live before that date. No extension was available; if the build overran, the practice would be without a live site.
The agency’s workbook specified every URL to carry over, every redirect, every meta title and description. One structural question required explicit scoping: the legacy platform hosted a /library/ section with dozens of sub-pages on dental education content that were not in the agency’s sitemap. The decision whether to migrate those sub-pages or exclude them belonged to the agency, not to us. We confirmed the scope boundary, excluded the library sub-pages as instructed, and ensured the library section’s incoming links were handled in the redirect map.
The specification also included meta-data accuracy checks: the QA pass identified instances of duplicate H1 text and duplicate meta descriptions that had persisted from the legacy platform. These were resolved against the workbook before handoff.
The stakes on this engagement were sharper than a typical rebuild. Missing a deadline on a project without a fallback platform is not an inconvenience; it is a period of no live presence. The agency needed a team that would hold the estimate, hold the timeline, and not introduce scope drift that would eat into the countdown.
Risk context. The external constraint on this project was categorical: the legacy hosting platform was being shut down on a date the agency could not move. Every hour of overrun narrowed the window for agency QA before go-live. The conventional rebuild risk — a missed redirect eroding rankings — was still present, but secondary. The first-order risk was an overrun that compressed the agency’s sign-off window to the point where the practice went live with unverified work, or did not go live at all. Holding the 44.2-hour estimate precisely was not a quality-of-life feature; it was the condition that made an orderly handoff possible.
How We Did It
1. Template-first build. The full site collapsed into a consistent template set:
- Homepage, About, Contact, and Default fallback
- Services Lander + Service Page template covering the practice’s full treatment catalogue
- Doctor and Team Page templates for practitioner bios
- General content templates for non-service pages
Explicit scope boundary: the legacy platform’s /library/ sub-pages were confirmed out of scope with the agency before development began. Incoming links to that section were handled in the redirect map rather than via page migration.
2. Spec followed line-for-line, from the agency’s sheet. Every target URL, every redirect, every meta title and description came from the workbook. Duplicate metadata found during QA — identical H1 text across multiple service pages, carried over from the legacy platform’s templating — was flagged and corrected against the workbook’s per-page specifications before handoff. Where the workbook specified a value, that value landed on the new site.
The principle: the spec is the contract. When the legacy platform has seeded content anomalies into the data (duplicate titles, duplicate descriptions, templated filler text), cleaning them up means reading the workbook more carefully, not improvising corrections.
3. Crawl-based verification, not “looks fine to me”. Before DNS cutover, Screaming Frog ran against both the staging rebuild and the legacy platform. Status codes, redirect chains, meta-tag parity — every delta reconciled against the workbook. The library section exclusion was verified: no library sub-page paths appeared as live URLs on the new site, and the redirect map covered the section’s main entry point. A second crawl after go-live confirmed internal links resolved on the live domain.
4. Launch checklist, closed before handoff. Design, functionality, content accuracy, SEO and analytics, responsive display, and DNS migration to WP Engine — all closed before handoff. The timeline discipline was a direct requirement of the platform-shutdown constraint; the checklist was compressed, not shortened.
Working under the platform-shutdown deadline meant the spec had to be read before a single page was built — the order was not optional. The 44.2-hour estimate held because the redirect map and the metadata corrections were both cleared against the workbook before DNS cutover, leaving the agency a full QA window before the June 1 date.
Results
| Metric | Outcome |
|---|---|
| Spec fidelity — redirects | All agency-specified URLs redirected; library section boundary enforced |
| Spec fidelity — meta data | All meta titles and descriptions placed as specified; duplicate metadata corrected against workbook |
| Spec fidelity — templates | Complete template system built and applied site-wide |
| Scope boundary | Library sub-pages correctly excluded; main library entry point handled in redirect map |
| Timeline | 20 days, delivered on schedule — before platform shutdown date |
| Effort | 44.2h / 44.2h estimate — no overrun, no scope creep |
| Responsive verification | Zero layout issues across 4 browsers × 6 viewports |
| Internal QA | All agency-scoped issues closed before handoff; post-launch agency QA round addressed additional content refinements in a retained sprint |
| Handoff | Site live on WP Engine before the platform shutdown date, no downtime |
| Site status | amazingsmilelv.com live in production |
The outcome, restated plainly: the agency’s spec was implemented as written, inside the quoted hours, before the platform shutdown date. The estimate held; the handoff window was preserved.
Operational Integrity at handoff
Pre-handoff QA caught duplicate meta descriptions carried from the legacy platform across service pages — confirmed manually per page — and a noindex state incorrectly set on Invisalign sub-pages, both resolved against the workbook before the staging build left our hands. 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.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Brief & estimation | 4 days | Agency spec reviewed; library scope boundary confirmed; 44.2h quoted and agreed |
| Development | ~12 days | Full site rebuilt across all templates; library section excluded per spec |
| Internal QA & review | 2 days | Duplicate metadata corrected; all agency-scoped work cleared before handoff |
| Spec verification | 1 day | Meta, redirects, and scope boundary reconciled against workbook |
| Delivery & DNS cutover | 1 day | Site live on WP Engine, no downtime — before platform shutdown date |
Phases overlap (QA ran alongside late development), which is why the calendar timeline is 20 days rather than the sum of individual phases.
Team
Delivery team
- Nikita Tumasevic — lead developer (full site build, template system, and redirect implementation)
- Anna Polunina — development support and estimation
- Evgeniy Karpov — content QA and meta-data corrections
- Pavel Sazhin, xaverPRO — QA and delivery oversight
- Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)
All URL-preservation, redirect-strategy, and scope-boundary decisions belonged to the agency; our role was implementation fidelity to the spec they delivered. The agency remained the visible vendor; we were invisible to the end client throughout.
For agencies considering a white-label WordPress build
If your agency is managing a platform migration with a hard external deadline, send us the migration spec and the cutover date.
We will return a fixed-hours estimate within 24 hours, flag the scope items most likely to compress your QA window, and confirm what we need to start — no cost, no obligation to proceed.
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.