28-Page Veterinary WordPress Build in 32 Days — White-Label Delivery for a US Marketing Agency

The Craft of a Build

28 pages of a veterinary WordPress build from Figma designs and a Google Doc content spec — no existing website to validate against, no crawl baseline to diff. We checked every template choice, content block, and slug against the design file. The per-row hours we scoped held at 43 hours across 32 days.

Snapshot

The Brief

Stonebridge Veterinary Wellness is a companion animal practice in Roseville, California — multi-doctor, full-service, offering preventative care, surgery, dentistry, pain management, urgent care, and pet transport. A US marketing agency specialising in local-business websites engaged us to build the practice’s first WordPress site on WP Engine using Elementor Pro.

The situation was greenfield from the start: no existing website, no live front-end to reference, no crawl baseline. The agency’s brief was a Figma design file, a shared Google Doc with per-page content, and a workbook sitemap of 28 URLs, which we then scoped row by row in hours. The agency owned design, content strategy, and the client relationship. We owned the build: setting up the WP Engine environment, constructing each URL against its assigned template, wiring Gravity Forms, configuring Yoast meta fields per the workbook’s per-row values, and working through post-build QA and fix rounds.

The ask was direct. Build all 28 URLs into the agency’s 9 standard templates. Follow the Figma layouts and the content doc line-for-line. Hold to the per-row hours we scoped — that scope is the contract. Surface ambiguity back to the agency, and do not improvise design or SEO decisions. Where the agency’s spec was silent, flag it rather than guess.

How We Did It

1. Nine templates, 28 URLs, one build pipeline. Stonebridge’s pages spread across the agency’s standard local-business template library: Homepage, About Us, Services Lander, Service Page (applied 6 times — pet dentistry, pet transport, preventative care, surgery, pain management, urgent care), Doctor Page (4 doctors), Blog Lander, Contact Us, and a Default Template that caught 6 supporting pages (new-clients, testimonials, terms-conditions, privacy-policy, and 2 utility pages). Whatever template the sitemap row named, that is the one the page got — nothing was assembled freehand outside the library.

2. Spec followed line-for-line, within the hours we scoped. We scoped each sitemap row in hours — 2.0 for the Homepage at the top end, 0.5 for a standard utility page at the bottom. Summed, the per-row build work totalled 14.7 hours, and the balance of the budget went to management, QA, and fix rounds. None of it spilled past the 43-hour quote.

When a sitemap is priced row by row before a line of code is written, that pricing is what we sign up to honour. Our part was to land each page inside the number already attached to it, rather than reopening the cost of the page once we were mid-build.

3. Redirect paths mapped for future expansion. Eight redirect paths were provisioned in the sitemap — legacy-style slugs and alternate paths that the agency intended to resolve post-launch. We mapped each in the workbook’s redirect column, confirmed clean 404 responses on the staging environment where no live source existed, and left the redirect table ready for the agency’s DNS cutover. Provisioning them while we built, instead of patching them in once traffic was already hitting the new domain, meant the agency inherited a redirect table that was already settled the moment the domain switched over.

4. Two parallel QA loops, closed before handoff. Issues were tracked in two agency-side tabs — the Issues Backlog (20 actual rows, 18 closed as Completed, 2 in To Do) and the AM QA of Staging Site review (50 actual rows, 31 closed as Completed, 18 in QA, 1 in To Do). The 29-item launch checklist — Design, Functionality, Pre-Migration, and Domain phases — closed behind both backlogs.

The content spec exceeded what the service-page template could hold — multiple service descriptions ran long enough that fitting them required iterative trimming across client review rounds before the pages held their layout. Working that constraint into the build order, rather than treating it as a QA afterthought, kept the two parallel backlogs from stacking up at handoff.

Results

Where this settled: the agency’s 28-URL greenfield build shipped across 9 templates on the WP Engine environment, inside the 43-hour quoted budget. Two QA backlogs were worked down to agency-acceptance levels and the launch checklist closed before handoff.

Operational Integrity at handoff

The AM QA pass on the staging build surfaced two non-functional link findings — a “Directions” stub in the footer and contact sidebar that resolved to nothing (a Figma placeholder never wired to a live URL), and a “Contact” anchor on the doctor bio page that fired no navigation — both flagged in the workbook backlog and resolved before handoff. Before anything left our hands it went through Site Checker. How we run QA lays out the categories and the bar a page clears to ship. Once the build was theirs, the agency ran its own pass on its own stack, and whatever surfaced went back into the shared backlog for us to clear up to sign-off.

Process

Phases overlap — the AM QA loop began before every build-phase item had closed, which is why the calendar timeline is 32 days rather than the sum of individual phases.

Team

Delivery team

• Pavel Sazhin — lead developer and QA (build, template implementation, backlog resolution)
• Anna Polunina — build support and content integration
• Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)

Throughout, the partner agency held project management and every client-facing conversation. Stonebridge signed off on a site presented under the agency’s brand and had no occasion to learn that a separate WordPress team had assembled it — exactly how a white-label arrangement is meant to read from the client’s seat.

For agencies commissioning a white-label WordPress build