Edge computing for small teams

Most teams know this matters. Fewer have decided who owns it. Most advice about edge computing assumes a team that does not exist at your size. Here is the version that does not.

Operability is a feature, and it has to be built rather than bought. Assume whoever inherits this will have half your context and none of your patience.

What to keep

Running closer to users removes latency you cannot optimise away. The cost of getting this wrong is rarely visible on the day it happens. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. Where this goes wrong is almost never a lack of knowledge.

What good looks like

Debugging across many locations needs deliberate tooling. The teams that handle this well are rarely the ones with the biggest budgets. Doing this properly once is usually cheaper than doing it approximately three times.

What this looks like day to day

The bill is a design document: it tells you exactly what your architecture actually does. Three things worth confirming about edge computing before you move on:

• Someone can say what the current setup is without going to look
• Debugging across many locations needs deliberate tooling — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.