Third-party scripts: the questions we get asked most

The advice here is unglamorous, which is probably why it gets skipped. The questions about third-party scripts that come up most often on our calls.

Most development decisions are really maintenance decisions wearing a different hat. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

Do we need to care about this?

Every tag you add is code you do not control. It is worth being explicit about, because assumptions differ quietly. Budget a little time for it every quarter and it never becomes a project of its own.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. The cost of getting this wrong is rarely visible on the day it happens.

How do we know it is working?

Audit the list twice a year and cut what nobody reads. Getting it slightly wrong is survivable. Ignoring it entirely is not. Doing this properly once is usually cheaper than doing it approximately three times.

What this looks like day to day

The question is rarely whether something can be built, but what it costs to keep running afterwards. Three things worth confirming about third-party scripts before you move on:

• Someone can say what the current setup is without going to look
• Every tag you add is code you do not control — 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.