A yoga-teacher academy's course launches stopped falling over under their own traffic

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

A yoga-teacher training academy runs multi-week certification cohorts that enroll through launch windows: an email goes out, the cohort fills within days, and the rest of the year is quiet. Its site is a WordPress install with a heavy page builder attached to a membership platform that handles courses and payments. Marketing is run by the founder with a part-time assistant; there is no technical staff. Launch days are the only days the site matters commercially, and they had never once gone smoothly.

What it was costing

Enrollment days for each cohort crashed the academy's site — the host scaled CPU, not concurrency, and launch-day email drove thousands of simultaneous readers to a WordPress install with a heavy page builder; the last launch lost an estimated day of enrollments.

What they could see

• On the last cohort launch, the site returned error pages within minutes of the email going out.
• The crash cost a full day of enrollments by the team's own estimate, because the site recovered too late.
• The host's dashboard showed plenty of CPU headroom during the crash, so nobody could explain the failure.
• Marketing staff planned launch days around the site instead of the other way around, drafting fallback posts.
• Between launches the site was fine, which made each crash feel random and impossible to plan for.

The constraints we worked inside

• The academy runs launches, not constant traffic — the platform must handle spikes 99% of the year doesn't see.
• Course content sits in a membership plugin the academy depends on; it must keep working during and after migration.
• Budget is fixed; the solution must be cheaper at rest than the anxiety it replaces.

What had been tried before

The host was upsold a bigger plan with more CPU before the last launch.

The host scales CPU, not concurrency — the crash pattern on enrollment day repeated almost identically on the larger plan, at higher monthly cost.

The launch email was split into three staggered sends to spread the crowd out.

Each send recreated the same burst minutes apart, and the waves overlapped as early readers returned to the page — the spike kept its shape.

A caching plugin was tuned on the WordPress install to take pressure off PHP.

The page builder's per-session scripts and membership checks stayed uncachable on exactly the routes the emails linked to, so PHP still took the full burst.

What we proposed

We proposed splitting the launch surface from the membership core: marketing and course pages rebuilt as statically generated Next.js routes on Vercel, with enrollment and member content staying exactly where they are on the existing platform behind their own subdomain. The reasoning: launch-day traffic is reading, not transacting — readers browse launch pages and only touch the membership island at enrollment — so the spike should hit static files at the edge while the plugin investment survives untouched. A load test replaying the real launch-email click curve would prove the path before the next cohort opened.

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

• Rebuilding the membership layer on a self-hosted LMS — Mid-cohort migration risk to the one system that never failed, plus a fixed budget with no room for a re-platform; the academy's courses and payments already work.
• A bigger hosting plan with autoscaling PHP — The host scales CPU, not concurrency — the identical failure shape already repeated on the last upgrade, and cost at rest rises year-round for spikes the calendar announces months ahead.
• A CDN in front of the existing WordPress site — The page builder emits per-session scripts and uncacheable markup on exactly the routes launch emails link to, so the edge would absorb the easy traffic and leave the burst on origin.

How the work ran

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

The stack, and the reasoning

Next.js

Launch pages need to be pure static routes the edge serves at burst speed; the framework made that the default rather than a fight with a page builder.

Vercel

Cost at rest stays near zero between launches — the budget is fixed — while launch-day bursts are absorbed without pre-provisioning anything.

Static generation

Enrollment emails link to pages built ahead of time, so the spike reads files instead of PHP — removing the concurrency ceiling that killed past launches.

Membership platform (retained)

The academy's courses, payments, and member content live there and work; migrating mid-cohort would risk the one system that had never failed.

Load testing

Replaying last launch's traffic pattern proved the new path before a real cohort bet on it; without that, it should hold is a guess, not a plan.

What went wrong

How we worked together

Cadence

Weekly Thursday calls with the founder between teaching blocks, a Saturday rehearsal session when the studio was empty, and a shared chat channel through launch week.

Client side

The founder owned launch content and the email plan; her part-time assistant tested the enrollment path end-to-end on her own devices.

Decisions

The founder made every call the same day it was raised; budget was fixed, so trade-offs were spelled out in writing with a single recommendation.

They provided

Last launch's email and analytics for the traffic replay, a sandbox tenant on the membership platform, and two hours of the assistant's time weekly.

What changed

The headline: latest cohort launch served record traffic with zero errors and enrollments up — Crashed launches → static launch pages, read from Launch-day analytics + error logs. A second check: launch-day enrollments vs the prior cohort at +24%.

Launch days changed character. The founder's assistant spent the last launch answering enrollment questions from the shared inbox instead of refreshing an error page, and the launch email went out without a paragraph of apology in case the site fell over. The membership platform reads as theirs again rather than a source of dread. And because the rest of the year costs almost nothing, nobody opens the hosting bill with the old suspicion that quiet months are overspending.

The result was read from Launch-day analytics + error logs against the pre-engagement baseline over the stated window, with a guardrail check on launch-day enrollments vs the prior cohort. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• A repeatable launch runbook: static build checklist, DNS checks, and go-live timing.
• The load-test suite with the real click-curve replay, runnable before each cohort opens.
• Vercel project access under the academy's own account, with billing and team roles set.
• A documented enrollment-path map showing what stays on the membership platform and why.