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.
What actually breaks
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.
What running the machinery after launch actually looks like
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 four questions on an ongoing basis, and can answer each one without waiting a week to find out.
What arrived this week, and from where? Not a dashboard nobody opens — a number a person actually looks at and reacts to, broken down by the channel that produced it.
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 until the quarter is already over.
What broke? Forms silently stop delivering. Pages fall out of the index. Certificates lapse. These are unglamorous, and over a year they cost more than any single positioning decision did.
What did we learn that changes the claim? The first version of the pitch is a hypothesis. The market answers it — in the questions prospects ask, the pages they linger on, the demo requests that stall — and the answer should reach the copy within weeks, not at the next funding round.
None of these questions is expensive to answer. They’re expensive to forget to assign, which is what happens by default once the launch team is gone.
Who this applies to
This isn’t specific to venture-funded biotech, and it isn’t specific to software. The pattern shows up wherever a market entry gets scoped as a one-time project rather than a standing responsibility.
We see it on two kinds of company. The first is pre-revenue: a lab or founding team that has real data behind a discovery and needs a market before it can be a business — the launch is the whole story so far, and if the machinery behind it goes unowned, there’s no revenue underneath to notice. The second already has paying customers — a local service business with a site, a phone number, and a review profile that needs tending every week, not once a year. MedGenie runs both kinds of engagement on the same operating model, because the underlying problem — a market entry with nobody assigned to run it afterward — is identical in both cases.
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 actually happens in the first 90 days with an operating partner is the mechanism that turns these four questions from an aspiration into a system somebody is accountable for.
How an operating partner differs from a launch agency
A launch agency is paid for a deliverable and is finished when it ships. An operating partner is paid to keep a result running, which changes what gets built in the first place: you design a site, a form, and a reporting layer differently when you know you’ll be the one maintaining them at 2am.
That same discipline is why the infrastructure underneath a launch matters as much as the positioning on top of it. It’s the reason Centauri Systems, the sibling side of this operation, runs enterprise API estates that carry billions of calls without going down — the same habit of building things to be operated, not just delivered, applies whether the estate is a payments API or a two-person company’s first website.
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 — and it’s the question worth asking before the launch date gets fixed, not after: who owns this in month two?