Scaling for a launch or campaign: what to prepare
How to get a business website ready for a product launch, a media moment or a campaign, so the traffic you paid for does not break the thing it lands on.
The short answer
A launch or a campaign concentrates traffic in minutes on a few pages and a few flows. A static site served from an edge network handles the page views by construction, so preparation goes to everything that is not a static page: the landing pages’ weight, the sign-up or order flow and the functions behind it, the third-party services with their sending limits and API quotas, the provider caps that bound cost, and the people who will be watching. Prepare in that order, test the exact flow under load with real numbers from the campaign plan, freeze changes before the day, and have rollback and fallbacks ready. Done this way a campaign is uneventful for the infrastructure and the attention goes to what the visitors do; done by hoping, the traffic you paid for lands on a form that stopped working at the tenth submission per second.
What to prepare
| Area | What to do | Why |
|---|---|---|
| Landing pages | Build them light, static, measured on mobile; images optimised; no heavy scripts | They receive the concentration; speed is conversion |
| Forms and orders | Confirm rate limits, bot checks, function limits; add a fallback that stores submissions if a downstream service fails | The first thing to fail under load |
| Payments | Test the flow end to end; know the provider’s limits; have a hosted payment page as fallback | Failed payments are lost revenue |
| Third-party services | Check sending limits on email, API quotas on the CRM, plan tiers on booking and analytics tools; raise them in advance | A campaign finds the lowest ceiling |
| Provider caps | Set caps so cost is bounded, high enough that the campaign fits | Usage billing under a spike |
| Caching | Confirm the landing pages and assets are cached at the edge; warm them | Every request from cache costs nothing |
| Monitoring | Dashboards for traffic, errors, function duration, form success rate; alerts to the people on duty | You must see a problem before customers report it |
| Change freeze | No deployments from the day before until after the peak | Incidents at a launch are self-inflicted |
| Rollback and holding page | Previous version one click away; a holding page ready for any failing section | Recovery in minutes |
| People | Named person watching at each push time, with the partner reachable | Someone must act |
The two weeks before
- Write down the numbers: reach, expected click rate, peak minute, submissions per minute, and double them.
- Build and measure the landing pages on a phone on mobile data.
- Walk the flow as a customer, on the preview, from the ad click to the confirmation email.
- Check every third-party ceiling and raise plans or limits in advance.
- Load test the flow at the doubled numbers; fix what breaks.
- Set caps, alerts and dashboards; agree who watches when.
- Prepare fallbacks: submission storage, hosted payment page, holding page.
- Freeze changes the day before; confirm rollback works.
On the day and after
Watch the dashboards at each push, especially form success rate and error counts, not just traffic. Do not deploy. If a flow degrades, switch to its fallback rather than debugging live. Afterwards, process any stored submissions, review the logs for limits hit, note the real peak numbers for next time, and lift the freeze. The record of what happened is the plan for the next campaign.
What this means for you
Prepare a campaign by making the landing pages light and static, testing the sign-up and order flows under the doubled expected load, checking and raising every third-party limit, setting caps and alerts, freezing changes and having rollback and fallbacks ready with someone watching. The static pages will take care of themselves; the preparation is for the flows and the services behind them, which is where campaigns break when nobody looked.
Frequently asked questions
Our site is static. Do we need to prepare at all?
The pages will be fine; they are files on an edge network built to serve millions. The preparation is for everything that is not a file: the sign-up form and its function, the payment flow, the email service's sending limits, the CRM's API quota, the booking tool, the analytics. Each has a ceiling, and a campaign finds the lowest one. Preparation is finding it first.
How much traffic should we plan for?
Take the campaign's reach estimate, assume a realistic click rate, and concentrate most of it in the first hour after each push. Then double it. That number, as visitors per minute and form submissions per minute, is what the flows and the third-party limits are tested against. A television mention or a viral post can exceed any plan; the static pages absorb that, and the dynamic flows degrade gracefully if prepared.
What if something breaks on the day?
You roll back to the last known-good version in one step, or you switch the affected flow to its fallback: a form that stores submissions for later processing, a payment link on the provider's hosted page, a holding page for a broken section. Those fallbacks are decided and tested before the day, and someone is watching who can trigger them. The campaign is not the time to improvise.