1 min read

I launched the same website, not once but five times

Same product, same company, same team, same process.
I launched the same website, not once but five times

Five internationalised website launches. German, French, Spanish, Dutch, and Italian. Same product, same company, same team, same process.

Different language. Same surprises.

Every launch, without fail, there's a piece of content someone assumed was covered and wasn't. A form that's still rendering in English on a Spanish staging environment. An animated asset that wasn't included in the localisation brief because nobody thought to include it.

You'd think by launch four you'd have closed these gaps. You mostly have. But the ones that remain are the ones that were always hard — the things that live in the space between two teams, between an internal deliverable and an agency dependency, between what the brief said and what both sides understood it to mean.

The brief always has a hole in it. Not because the people writing it are incompetent — but because a brief is a compression of reality, and compression always loses something.

The question isn't how to write a perfect brief. It's how to build a process where the gaps surface early, when they're cheap to fix, rather than at 4pm on launch day when they're not.

We use a sign-off checklist. We do a pre-launch risk review. We have explicit severity levels so that when something surfaces, nobody's arguing about whether it's a blocker — the framework already decided.

It doesn't prevent surprises. It just means the surprises are smaller and the response is faster. What does your launch process do about the things everyone assumed someone else was handling?