A tourism board's festival weekends stopped being an outage lottery

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

The organization promotes a coastal region to visitors, running the official tourism site: maps, event listings, seasonal itineraries, and road information. Staff is small — a marketing lead, an events coordinator, and a rotating cast of volunteers who keep festival listings current. The site's load profile peaks brutally: a handful of festival weekends and weather events draw most of the year's traffic, then usage falls back to a trickle. The budget comes from lodging taxes and membership dues, and the board guards it — infrastructure that sits idle for fifty weeks is a hard sell.

What it was costing

Festival weekends tripled site traffic exactly when visitors needed maps, schedules, and road closures; the aging CMS slowed to a crawl under the spike, and the organization had no budget for infrastructure it pays for fifty weeks a year.

What they could see

• Festival lineup announcements made the site unusable for an hour exactly when visitors were searching for it.
• During one weather event, the road-closures page wouldn't load while the office's phone lines lit up.
• The admin dashboard slowed to a crawl under traffic, so volunteers couldn't even correct wrong information mid-spike.
• A slow third-party map made the schedule page feel broken on phones even on ordinary days.
• Volunteers needed a staff member to publish anything, so event updates waited in inboxes for hours.

The constraints we worked inside

• Content is published by a rotating cast of volunteers and staff with minimal training — the editing workflow cannot get harder.
• Traffic spikes are predictable but sharp — weather announcements, lineup drops — so scaling must be automatic and fast.
• The site carries embedded third-party maps and widgets that cannot be re-negotiated.

What had been tried before

A burst-capacity tier was bought from the managed CMS vendor for the two festival weekends each year.

Extra capacity arrived slower than the spike; the CMS admin and database choked first, and the plan still cost real money for days that stayed quiet.

A technically minded volunteer hand-stripped the homepage before festival weekend — fewer images, fewer widgets, one lightweight page.

It depended on one volunteer's availability and nerve, the stripped page lost the map embeds visitors needed, and restoring it afterward took longer than the festival.

Publishing was paused during peak windows to keep the site stable when crowds arrived.

Freezing publishing during festival weeks is backwards — lineup changes and road closures are what visitors needed updated, so stale pages caused their own complaints.

What we proposed

We proposed moving the site to a statically generated Next.js build on Vercel with on-demand revalidation: pages render ahead of the crowd, and publishing a lineup or closure refreshes the affected pages in seconds. Editing moves to a headless CMS with a deliberately simple, one-field-per-thing surface — the constraint was that volunteers' workflow can't get harder, so it had to get easier. Third-party maps and widgets, which can't be renegotiated, load lazily inside performance-budgeted sections so a slow embed degrades itself instead of the page around it.

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

• Paying the managed CMS's burst tier for festival weekends — Provisioning takes longer than a lineup drop travels, the CMS admin itself was the bottleneck under load, and the budget rule forbids infrastructure priced for fifty-one quiet weeks.
• Server-rendered pages with an aggressive cache layer — Freshness would depend on cache-expiry guesswork; revalidation ties updates to the act of publishing, which matches how volunteer editors actually behave.
• Replacing third-party maps with self-hosted mapping — The embeds carry official county road-closure data we can't reproduce, and renegotiating vendors was out of scope — isolation had to happen on our side.

How the work ran

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

The stack, and the reasoning

Next.js

Static routes revalidate on publish, matching how volunteer editors work — freshness tied to the act of publishing, not to cache-expiry guesswork.

Vercel

Automatic instant scaling absorbs lineup drops and weather announcements while costing nothing extra across the fifty quiet weeks the board actually funds.

On-demand revalidation

Publishing a road closure refreshes that page within seconds without a full rebuild, keeping the edit-to-live path short enough for untrained volunteers.

Headless CMS

A one-field-per-thing surface hides the old dashboard maze; the editing workflow gets simpler, which the rotating volunteer cast requires to function.

Lazy embeds

Third-party maps and widgets can't be renegotiated, so isolating them inside performance budgets is the only way a slow map stops holding pages hostage.

What went wrong

How we worked together

Cadence

A Monday check-in with the marketing lead, a biweekly working session with two volunteer publishers, and a one-paragraph update for the board's monthly meeting.

Client side

The marketing lead owned content-structure decisions; two long-serving volunteers tested the editing surface and became the trainers for the rest.

Decisions

Workflow decisions were made in the volunteer sessions by trying them; budget questions went to the marketing lead, who carried them to the board.

They provided

The CMS export and media library, an afternoon with the county's road-closure contact to document the embed's data source, and volunteer time for training.

What changed

The headline: two festival weekends served at peak with response times flat against baseline — Outage lottery → cached festival weekends, read from Festival-weekend monitoring. A second check: hosting cost vs the previous managed cms stack at −64%.

The site stopped being something the staff apologized for. Volunteers publish lineup changes themselves in minutes and watch the page refresh, which turned festival week from a triage shift into ordinary work. The marketing lead stopped carrying a private list of what was broken. Weather announcements — the highest-stakes publishing the organization does — now go out with the same confidence as a menu update, and the board has stopped discussing the website as a recurring line-item risk.

The result was read from Festival-weekend monitoring against the pre-engagement baseline over the stated window, with a guardrail check on hosting cost vs the previous managed cms stack. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• A volunteer training guide built from real festival content, including the layout that bit us.
• The headless CMS with editing roles and the one-field-per-thing content model documented.
• Revalidation behavior notes: what refreshes on publish and what waits for the next build.
• A festival-weekend monitoring dashboard with alert thresholds recorded and owned by the marketing lead.