47-URL Multi-Location Day Spa WordPress Build

Client (end user): Radiant Day Spa — Bend, Oregon (with Sisters and Jacksonville locations)
Engagement: White-label development for a US marketing agency
Delivered: September – December 2025 · 103 days · 138 hours across the build and its long fix-and-feedback tail

The Craft of a Build

A 47-URL Wellness build for a three-location Oregon day spa — where the conversion primitive was not a single contact form but a 33-treatment × 3-location booking matrix of per-service Square Appointments URLs. The agency’s staging review flagged that every “Book Now” button was routing to the location-wide service list rather than the specific treatment, forcing a treatment-by-treatment rewire before a guest scrolling a treatment menu could land on the right Square embed.

This case study is a record of one such build — delivered for a US marketing agency in the wellness day-spa segment — and it is the first Wellness-industry case in our portfolio.

Snapshot

The Brief

A US marketing agency retained by Radiant Day Spa — a three-location wellness practice serving central Oregon from sites in Bend, Sisters, and Jacksonville — handed us a Google Sheets workbook with a sitemap of 49 rows resolving to 47 unique URLs, a 14-template Figma library, a 30-row launch checklist with Development / Pre-Launch / Both columns, an AutoQA Setup tab the agency runs against staging, and two empty issue-backlog tabs (DEV for developer-impacting items, CX for client-experience items) ready to fill once staging went up. The build sat on the agency’s Kinsta environment; SEO came from Rank Math Pro; performance from WP Rocket; and the conversion primitive — the thing a guest does on the site — was a set of Square Appointments embed widgets, one per location. Figma carried the homepage and treatment-page designs.

The ask was a single-phase build with a long reconciliation tail. Build all 47 URLs into the agency’s nine applicable templates; wire the multi-location booking logic so that each treatment’s “Book Now” button resolved to the right embed (direct for a treatment offered in only one of Bend / Sisters / Jacksonville, popup picker for treatments offered in two or three); then, through a stretch of weeks against staging, work down the DEV and CX backlogs in parallel and close the launch checklist. The agency owned strategy, copy, treatment menu, brand voice, and client-facing communication. We owned execution: templates, page wiring, booking-matrix logic, QA discipline, no improvisation on copy or design.

This was a net-new build with no inherited URL space and no migration. There is no “before” state to compare to, no rankings to preserve, no redirect map to honour — there is the workbook the agency wrote, the staging site we built against it, and the live site that finally cut over. The pre/post framing some Build cases lean on does not apply here.

How We Did It

1. Nine templates, 47 URLs, one build pipeline. Radiant Day Spa’s URLs spread across nine of the agency’s 14 standard templates: Homepage (1), Services Lander as the treatment-menu lander (1), Service Page (33 — the heaviest by far, one per treatment), Location (4), About Us (3 — one per location), Reviews (3 — one per location), Blog Lander (1), Blog (1), Loyalty Program (1). Each URL was built on its assigned template per the sitemap row; nothing was hand-rolled outside the template system. The agency’s library also carries a Doctor Page template — appropriate on a healthcare build, not on a day spa where the conversion pages are treatment menus rather than provider bios — and we left it unused.

2. The workbook is the contract — including the per-row Hours Estimated column. The agency’s Sitemap tab carried an Hours Estimated value on every row (Homepage at 12 hours, About-Us pages at 0.5 hours each, treatment pages typically at 1 hour, the Services Lander and Location pages priced higher). The aggregate of those row values represented the build estimate; the 138-hour project estimate carried that build aggregate plus the QA, project management, and post-staging reconciliation budgets. Both held against actuals.

The discipline this represents is straightforward. On a build with a pre-costed sitemap, the dev team’s job is to deliver inside the row-level budgets, not to re-open pricing page by page. We honoured the row figures and surfaced surprises back to the agency rather than absorbing them silently into the next row.

3. The multi-location booking matrix. This was the load-bearing piece of custom development on the build. Each of the 33 treatments carried a location-availability flag — BD (Bend), SS (Sisters), JV (Jacksonville), or some combination. The “Book Now” affordance behaved differently per case: for a treatment available at one location, it linked direct to that location’s Square Appointments embed; for two- or three-location treatments, it opened a picker popup with one option per location, each option carrying its own Square embed code. We implemented the matrix once against the agency’s spec, exposed it in the Service Page template via a small custom field set keyed to the BD/SS/JV flags, and then defended it through both QA backlogs as the agency added, removed, and re-tagged treatments through the long tail. We opted for the custom-field approach over separate per-location-treatment pages because the workbook listed 33 treatments with overlapping location flags — keeping each treatment on a single URL with embed routing in the custom field set held the template count at 9 instead of multiplying it by the number of locations offering each service. The booking widget — Square Appointments — sits in the Tech Stack row of the Snapshot for a reason: on a wellness build it is the conversion primitive, in the way Gravity Forms is on a healthcare build.

4. Two parallel QA loops, worked through a long staging-feedback tail. Issues were tracked in two agency-side backlog tabs: Issues Backlog DEV held the developer-impacting items (layout regressions, broken links, missing content rows, image swaps, the booking-matrix edge cases as they surfaced). Issues Backlog CX held the agency’s account-side concerns (copy edits, image-replacement requests, brand-voice corrections, location-specific content asks routed back to the end client). Of the 49 DEV items raised, 26 closed as Completed; 10 sat in QA awaiting agency or end-client confirmation, 9 were To Do, 3 In Progress, 1 held on Info Needed at handoff. Of the 51 CX items raised, 19 closed as Completed (one additionally marked closed); 15 in QA, 3 To Do, 1 In Progress, 13 held on Info Needed pending agency or end-client decisions. The 30-row launch checklist — Development / Pre-Launch / Both — closed at 24 items signed off behind both backlogs, with the residual six checklist items themselves dependent on the same Info-Needed waits.

Issue #1222 — “The Book Now logic” — cost 14 hours against a 4-hour estimate, a 3.5× overrun that tells you what the load-bearing piece of the build actually was. The booking-matrix reconciliation, not the page build, was where the engagement’s time went; the two parallel QA backlogs running alongside it across 103 days kept every other fix in the open rather than backlogged silently.

Results

The outcome, restated plainly: the agency’s 47-URL multi-location day-spa build shipped across 9 templates on Kinsta, inside the 138-hour quoted budget. Two QA backlogs ran in parallel through a long reconciliation tail; 45 of the 100 raised items closed as Completed before the end of our engagement, with the remainder split between in-flight QA and Info-Needed waits on agency or end-client decisions. The launch checklist closed at 24 of 30 signed-off items; production cut over at the end of the 103-day window.

Operational Integrity at handoff

Pre-handoff Site Checker ran on the initial build before the first agency review — QA flagged open findings («ммм-чекера и исправить косяки», chat #963, 2025-09-23) — and the agency’s post-handoff pass then raised #1222, which showed that every “Book Now” button across the 33-treatment matrix was routing to the location’s general Square service list rather than the per-treatment-specific booking URL. 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

Phases overlap heavily — the booking-matrix work began before every Service Page had finished its first build pass, and the DEV/CX reconciliation tail ran alongside both, which is why the 103-day calendar is materially shorter than the sum of individual phase durations.

Team

Delivery team

• Nikita Tumasevic — lead developer across the build phase and the multi-location booking-matrix piece
• Pavel Sazhin — QA iterations and fixes across both DEV and CX backlogs
• Timur Arbaev — QA support, with primary ownership of the long reconciliation tail (the largest single QA contribution on the project)
• Lyudmila Travkina — QA pass and pre-handoff review coordination
• Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)

Agency-side project management and client-facing communication remained with the partner agency throughout. Our team was invisible to the end client. Treatment-menu copy, brand voice, location strategy, and the booking-flow product decisions were the agency’s; the wiring of those decisions into a multi-location WordPress build was ours.

For agencies commissioning a white-label WordPress build