Post-launch support: the questions we get asked most

We end up explaining this on discovery calls often enough that it deserved writing down. The questions about post-launch support that come up most often on our calls.

The projects that go badly are rarely the ones with the hardest technical problems. Check it against what you would want a competitor's site to get wrong.

Do we need to care about this?

Launch is the beginning of the maintenance period. The cost of getting this wrong is rarely visible on the day it happens. It is the sort of thing that looks like polish right up until it costs you an enquiry.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. There is a version of this that is over-engineered, and it is worth avoiding.

How do we know it is working?

Budget for it or it comes out of goodwill. In practice this is a scheduling problem more than a technical one. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

What this looks like day to day

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
• 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

If you want a second opinion on how yours is set up, ask.