Five mistakes teams make with post-launch support
Every audit we run turns up some version of this. These are the ones we run into repeatedly when we audit post-launch support.
The projects that go badly are rarely the ones with the hardest technical problems. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
What to watch for
- Treating it as a launch task rather than an ongoing one
- Assuming someone else already owns it
- Launch is the beginning of the maintenance period
- Decide who owns fixes before you need them
- Never checking whether the fix actually worked
Budget for it or it comes out of goodwill. It is worth being explicit about, because assumptions differ quietly. If it only works because one person remembers to do something, it does not work yet.
What to do next
How to tell if yours is fine
Clear scope protects the client at least as much as it protects the agency. Three things worth confirming about post-launch support before you move on:
- Someone can say what the current setup is without going to look
- Decide who owns fixes before you need them — and you know whether that is true here
- There is a way to tell whether the last change to this helped
The point is not perfection, it is knowing which of these you have consciously chosen to skip.