Post-launch support, explained without the jargon

We end up explaining this on discovery calls often enough that it deserved writing down. Here is post-launch support without the vocabulary that usually surrounds it.

The projects that go badly are rarely the ones with the hardest technical problems. Write the reasoning down alongside the decision, because the reasoning is what changes first.

The short version

Launch is the beginning of the maintenance period. Small and consistent beats large and occasional here. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. Where this goes wrong is almost never a lack of knowledge.

Decide who owns fixes before you need them. Getting it slightly wrong is survivable. Ignoring it entirely is not. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Turning this into a decision

Budget for it or it comes out of goodwill. There is a version of this that is over-engineered, and it is worth avoiding. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

How to tell if yours is fine

Strategy work is mostly deciding what not to do, and writing it down so it stays decided. Three things worth confirming about post-launch support before you move on:

• Someone can say what the current setup is without going to look
• Budget for it or it comes out of goodwill — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.