You sell for five days a year. The site is quiet for the other three hundred and sixty, and none of that matters if it falls over on day one.
A course business is a spike business, and everything below is about the few hours when the spike arrives.
Launch traffic arrives within minutes of a send and lands on the checkout, which is the one page that cannot be cached. Capacity is reserved for that page rather than for the site around it.
Week three unlocks on the date the student was promised, not on the next page load. Release runs on a real scheduler, so a cohort that goes quiet still progresses.
A student watching a forty-minute lesson would otherwise hold a worker for forty minutes. Video is served away from the application entirely.
A cohort starts together and works through the same lesson in the same week, so load concentrates on a handful of URLs rather than spreading across the course.
The riskiest edits happen hours before the cart opens. Daily restore points mean a wrong pricing change is undone rather than debugged live.
Sizing a course site on its average traffic is sizing it for the wrong day. The only figure that matters is concurrent checkouts in the first hour.
The measure is not page speed on a normal day. It is whether the checkout completes while everyone who opened the email is trying to buy.
The traffic shape is a spike on a known date, and every row is about surviving it rather than about the quiet months.
| Setting | What we do | Why |
|---|---|---|
| Checkout capacity | Reserved for known launch windows | Launch traffic lands on the one page that can never be cached, within minutes of an email being sent, on a date you already know. |
| Drip scheduling | Released by system cron rather than by page views | Content promised for a specific date has to unlock on that date even for students who did not visit, which WordPress's own scheduler cannot guarantee. |
| Lesson video | Served away from the application entirely | A student watching a long lesson would hold a PHP worker for its full duration, so a modest cohort can exhaust the pool by studying. |
| Cohort load | Planned around shared progression rather than spread | Students who start together reach the same lesson in the same week, so demand concentrates on a few URLs instead of distributing across the course. |
| Pre-launch restore points | Taken ahead of the cart opening | Pricing and access rules are edited under time pressure in the final hours, which is the worst possible moment to be debugging one. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Move the course across — migration is free, students included.