A vacation-rental manager's five brand sites went from shared-hosting fear to preview deploys and rollbacks

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

Five vacation-rental brands share one operation: a property management company handling guest bookings, cleaning turnover, and owner relations along a stretch of coastline. Each brand has its own website for browsing homes, checking availability, and asking questions; all five feed the same booking engine through iframes and redirects. Everything web-side ran from a single shared hosting account, one control panel, and one contractor relationship. Content changes went from the office to the contractor to the live sites by hand. Peak season runs June through August and carries most of the year's revenue.

What it was costing

Five brand sites shared one creaking host; a plugin update to one took down all five one August weekend, and the manager's web contractor had no safe way to test changes — staging meant 'try it and see.'

What they could see

• One plugin update took all five brand sites down for an August weekend, right at the start of peak booking.
• Changes went live through FTP on the production host — there was no way to see a change before guests did.
• The same content edit had to be repeated across five sites by hand, and one always drifted out of sync.
• Nobody could say when the sites were last backed up or whether a restore had ever been attempted.
• A deploy meant holding your breath through the weekend; the contractor's phone was the only monitoring.

The constraints we worked inside

• The sites share a booking engine via iframes and redirects; the migration cannot break those integrations.
• Non-developers publish content; the deploy pipeline must be invisible to them, not another thing they can break.
• Peak season is sacred: no risky changes between June and August, which is exactly when changes get requested.

What had been tried before

The contractor kept a staging folder on the same shared host and copied changes over after a quick look.

Same host, same plugins, same server state — it validated appearance, not behavior, and the update that broke all five sites had passed that eyeball check.

Plugin and core updates were batched into one late-night session each quarter, so failures would land away from booking peaks.

Batching made every session a pile of unisolated changes; when one update failed, the whole weekend went to recovery instead of reverting one small thing.

An external monitoring service was subscribed to page the contractor whenever a site stopped responding.

Alerts arrived minutes after guests noticed, and with no rollback path they turned an outage into a documented outage — visibility without capability.

What we proposed

We proposed consolidating all five sites into one Next.js codebase with per-site configuration, deployed on Vercel, so publishing becomes a merge with a preview URL instead of an FTP session on a shared host. The reasoning: the brands share booking-engine integration code and a content rhythm, so one pipeline serving five configured sites removes the five-fold maintenance without changing what guests see. Rollbacks would be instant and rehearsed before go-live, and the peak-season freeze would be enforced by policy — changes review on previews all summer, production moves only when the office approves.

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

• Five separate Vercel projects, one per brand — Five pipelines and five configuration surfaces for a one-engineer engagement; the shared booking-integration code would be copied five times and drift apart within a season.
• A better shared host with a proper staging environment — Even a good host can't offer per-change preview URLs or tested instant rollbacks; every plugin update would still need the booking iframes re-certified — the exact failure mode we were escaping.
• Managed WordPress hosting with staging — It would improve the staging story but keep five installs or one fragile multisite, and the rollback and preview guarantees the freeze policy depends on still wouldn't exist.

How the work ran

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

The stack, and the reasoning

Next.js

One codebase serves five brands with shared booking-integration helpers, so a fix to the iframe embed pattern lands once instead of five times.

Vercel

Per-change preview URLs and instant rollbacks are the exact primitives the freeze-and-drill policy needs; the shared host offered neither at any price.

Preview deployments

Non-developer stakeholders approve changes by clicking a URL, keeping publishing visible without anything touching production during peak season.

Per-site configuration

Brand differences live in one config layer instead of diverging code, so adding or retiring a brand is an afternoon, not a contractor engagement.

Uptime monitoring

Alerts name the failing brand and the last deploy, so a two-in-the-morning page arrives with the first diagnostic step, not just a red light.

What went wrong

How we worked together

Cadence

A 30-minute Tuesday call with the property manager reviewed the week; heading into peak season, a written status note went to all five brand owners every Friday.

Client side

The manager owned priorities and the freeze calendar; the office manager tested content publishing; one brand owner joined reviews for anything guest-facing.

Decisions

Anything the Tuesday call couldn't settle went to a one-page decision note with options and a recommendation; the manager answered within two days.

They provided

Access to the shared host and booking-engine integration docs, an hour with each brand's content owner, and a date range for the incident drill.

What changed

The headline: all five brands live on vercel with preview-deploy reviews and tested rollbacks — Shared host → per-site preview deploys, read from Deployment log. A second check: peak-season outages since migration (vs 2 in the prior season) at 0.

The manager stopped treating the website as a shared liability. Brand owners ask for changes again, because a change is now a reviewable preview instead of a favor from a busy contractor. The freeze reads as a calendar policy the office can explain, not a superstition. And when something did break in the first season — a bad redirect, not an outage — the rollback was a click and a note to the brand owner, not a weekend.

The result was read from Deployment log against the pre-engagement baseline over the stated window, with a guardrail check on peak-season outages since migration (vs 2 in the prior season). Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• A documented incident drill with recorded rollback steps, rehearsed twice before peak season.
• Per-site configuration guide covering how to add or retire a brand site safely.
• Uptime monitoring with alerts routed to the office manager's inbox, tested end-to-end.
• A written freeze policy and preview-review checklist the office follows during peak season.