Skip to content
Insights

Why most launches die in the month after launch week

MG 3 min read

The pattern is consistent enough to be predictable. A company spends nine months on the science, six weeks on the launch, and then discovers that the week after launch is when the actual work starts — and that nobody is assigned to it.

Launch week produces a spike. The site goes up, the announcement circulates, a few hundred people who were already inclined to care show up and look around. Then attention decays, and what remains is whatever system was built to catch demand that arrives on an ordinary Tuesday four months later.

Usually there isn’t one.

The handoff that doesn’t happen

Most launches are structured as a project. There’s a scope, a deadline, a deliverable, and a team that disperses when the deliverable ships. That structure is fine for building a thing. It is actively wrong for entering a market, because entering a market is not an event that concludes.

What gets left behind after the project team disperses:

  • A site nobody has permission to change, so it doesn’t change
  • Analytics that were configured once and never read
  • A contact form routing to an inbox nobody owns
  • Content that stops the day the content budget stopped
  • Search rankings that were never going to materialise in six weeks, abandoned right before they would have

None of these are launch failures. Every one of them is an operating failure, and they all become visible about thirty days later — which is exactly when everyone has moved on to the next thing.

A market is a system, not a moment

The companies that compound after launch treat the launch as the point where the system switches on, not the point where the work concludes. Concretely, that means somebody owns these questions on an ongoing basis:

What arrived this week, and from where? Not a dashboard nobody opens — a number that a person actually looks at and reacts to.

What did we publish? Search traffic is a function of accumulated surface area. A site that stops adding pages stops growing, on a lag long enough that the causality is easy to miss.

What broke? Forms silently stop delivering. Pages fall out of the index. Certificates lapse. These are unglamorous and they cost more than any positioning decision.

What did we learn that changes the claim? The first version of the pitch is a hypothesis. The market answers it, and the answer should reach the copy.

Why this is a structural problem, not a diligence one

It would be easy to read this as a discipline failure — the team should have kept going. That misreads the incentive.

The people best equipped to run the system after launch are usually the people who built it, and they are almost never retained to do it, because “launch” is how the engagement was scoped and priced. The agency’s incentive is to ship and move on. The client’s incentive is to stop paying once the deliverable arrives. Both parties behave rationally and the system still ends up unowned.

The fix isn’t more diligence. It’s scoping the engagement around the thing that actually determines the outcome — whether the machinery is still running in month six — rather than around the artifact that’s easy to define and invoice.

What we do instead

We stay on as operator. The same team that built the thing keeps running it, which changes the design decisions upstream: you build differently when you know you’ll be the one maintaining it.

It also means what we learn on one company becomes tooling for the next. The second launch costs less than the first, and the fifth costs less than the second — not because anyone got faster, but because the parts that repeat stopped being rebuilt by hand.

That’s the whole argument for treating companies, rather than projects, as the unit of work.

  • go-to-market
  • operating

Building something that has to work?

Tell us what it is and by when it needs to be running.

Book a call