A self-storage group's rental-platform relaunch stayed clean through 20 sites with rollout QA and deployment support

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

Twenty self-storage sites run the same rental platform with site-specific pricing, local taxes, and three different gate-access systems, and the group was halfway through relaunching that aging platform site by site. Each go-live had found new breakage — pricing edge cases, gate-sync failures, broken move-in flows — and site managers had stopped trusting the system faster than fixes arrived. The relaunch vendor ships weekly, which is fast for them and fast for twenty sites betting their Saturdays on it. The group's own staff is one administrator; there is no QA function and no plan to hire one.

What it was costing

The group's aging rental platform was being relaunched site by site, but each go-live found new breakage — pricing edge cases, gate-access sync, move-in flows — and site managers lost trust in the system faster than fixes landed.

What they could see

• Every site go-live surfaced a new pricing or gate-sync defect the previous sites had not caught.
• Site managers worked around the platform with paper logs, then stopped reporting problems because fixes came too late.
• The same pricing edge case reappeared at a second site after being declared fixed at the first.
• Go-live weekends required the administrator and a vendor engineer on call, and still ended in rollbacks.
• No one could say which of twenty site configurations had actually been tested against the latest release.

The constraints we worked inside

• Twenty sites run on the same platform with site-specific pricing, taxes, and gate systems; one broken site breaks trust everywhere.
• The relaunch vendor's releases arrive weekly; QA must keep pace without hiring.
• Managers need a rollback story, not just a rollback plan — confidence is operational.

What had been tried before

Asked the relaunch vendor to add a QA pass before each weekly release.

The vendor tested against its reference configuration, not against the group's twenty-site matrix of prices, taxes, and gate vendors, so site-specific breaks stayed invisible.

Piloted each release on one friendly site before promoting it to the rest.

The pilot site's configuration was the simplest of the twenty; it approved releases that then broke the sites with split-rate pricing and the older gate vendor.

Kept a shared spreadsheet of known issues and workarounds for site managers.

The spreadsheet grew faster than it was read, managers kept private versions, and the group's administrator spent her week reconciling three lists of the same defects.

What we proposed

We proposed testing the site matrix rather than any single site: a configuration matrix drives end-to-end tests per site shape — pricing model, tax rules, gate-system vendor — so every release is checked against every configuration the group actually operates before rollout. Each weekly vendor release must pass the matrix suite plus a live smoke pass on the two pilot sites before any additional site flips, which replaces hope with a gate. The engagement's real deliverable is a runbook the group's own administrator runs — release, verification, rollback as procedures she owns, so the capability outlives the engagement.

Just as important is what we ruled out, and why:

• Freezing vendor releases until the group's internal QA matures — The relaunch timeline is contractual and the sites need it landed; a freeze trades one kind of risk for a delay the group cannot afford either.
• Hiring a dedicated QA engineer for the group — One hire cannot cover a twenty-site configuration matrix across three gate vendors, and the position would be the first cut when the relaunch ends.
• Per-site test suites written and maintained by the vendor — The vendor's interest is its platform, not the group's rollout; site matrices would rot exactly where nobody at the group could see or fix them.

How the work ran

Delivered by the systems pod — engineer over 9 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

Playwright

The rental flow is browser-only, and Playwright's traces let a non-developer administrator see exactly which step failed without reading test code.

TypeScript

The suite's future owner is an administrator, not a developer; typed fixtures serve as her documentation — each site's shape is declared in code she can read, with the compiler confirming her edits.

GitHub Actions

The group's administrator can read a workflow file and rerun a failed job herself; no external CI service meant one less vendor between her and the release gate.

Site configuration matrix

Twenty sites reduce to a handful of configuration shapes; testing shapes instead of instances keeps the suite small enough for one administrator to understand and extend.

Deployment runbook

The constraint was not writing tests but keeping releases gated after we leave; a runbook the administrator owns turns the gate into her routine rather than our promise.

What went wrong

How we worked together

Cadence

A Monday release-gate review with the administrator, midweek matrix triage she runs herself, and a fortnightly call with the vendor's release manager to close the notes gap.

Client side

The group's administrator owned the matrix, the gate decisions, and eventually the runbook; one regional manager represented site managers; the vendor participated in triage but never in gating.

Decisions

The administrator had final say on every site flip; the rule was simple — any matrix failure against a site's shape holds that site until it passes, no exceptions negotiated.

They provided

Site configuration exports for all twenty locations, gate-vendor documentation the group had collected, pilot-site manager time for smoke passes, and vendor release access.

What changed

The headline: remaining sites flipped on schedule with zero post-rollout pricing or gate incidents — Per-site surprises → gated rollouts, read from Rollout issue log. A second check: sites live on the relaunched platform with clean go-lives at 20/20.

Go-live weekends stopped being ceremonies. The remaining sites flipped on schedule behind a gate the administrator runs alone, and the smoke pass on the pilot sites became a ten-minute routine instead of an all-hands. Site managers' trust returned unevenly — paper workarounds disappeared first at the sites that had complained loudest, because they watched the gate catch problems first. The group now reads the vendor's weekly releases with a diff instead of dread, and the administrator describes the matrix as the first tool that respected how different her sites are.

The result was read from Rollout issue log against the pre-engagement baseline over the stated window, with a guardrail check on sites live on the relaunched platform with clean go-lives. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The test suite repository with the twenty-site configuration matrix and fixtures
• The GitHub Actions workflows and the release-gate checklist the administrator runs
• The gate-system simulator with per-vendor delay profiles and maintenance-window settings
• The deployment runbook covering release, verification, rollback, and escalation paths
• Administrator training sessions recorded for her successor or new site managers