Emergency response has a well-understood logistics problem and a much less discussed information problem. In the first two weeks, the constraint is rarely supplies — it is that nobody can reliably communicate from where the operation is happening, and nobody has a current picture of how large the affected area actually is.
Both are solvable faster than most programmes assume, and both are cheaper before the emergency than during it.
Week one: the team has to be able to report
A field location with no cellular coverage and no fibre needs a satellite terminal. That is the entire technology decision, and it is not complicated. What varies enormously is how long it takes.
A terminal shipped in from abroad, cleared, transported and commissioned by someone flown in for the purpose is a multi-week process in good conditions. A terminal installed by people already in the country, on a hub that is also in the country, is measured in days.
The location of the hub matters for a second reason in this context. If the teleport is abroad, coordination traffic between two field sites — or between a field site and a country office in Mogadishu — travels to another continent and back twice. For voice and coordination that is a real degradation, and it occurs precisely when people are trying to work quickly under pressure.
Week one: somebody has to see the area
The honest situation early in a flood is that nobody knows the extent. Field reports are partial by definition, roads are impassable, and the areas nobody can reach are frequently the worst affected.
Satellite imagery covers exactly that gap. Radar imaging works through cloud — which matters, because floods arrive with weather and optical imagery is useless under it. Inundation mapping can establish which settlements, roads and cropland are actually under water within days.
The operationally useful output is not the image. It is the derived number: how many people, structures and hectares sit inside the affected area. That is the figure every situation report needs on day two, and the one most often estimated.
Week two: the data needs somewhere to live
Beneficiary registration, assessment data and payment records accumulate quickly and are sensitive from the moment they exist. For many programmes, where that data sits is a funding condition rather than a preference — and Somalia has had a Data Protection Act since 2023, which applies to humanitarian data controllers as much as to anybody else.
In-country hosting closes that question early. Arranging it mid-response, while also running the response, does not go well.
The argument for arranging it in advance
Everything above is easier to procure in an ordinary month than in an emergency. A framework that can be activated — terminals identified, a hosting arrangement in place, an imagery tasking relationship established — converts a multi-week procurement into a phone call.
The obstacle is usually budgetary rather than technical: preparedness spending is hard to justify against a disaster that has not happened. The counter-argument is that the alternative is paying emergency prices for emergency timelines, and accepting the first fortnight as a write-off.
What this does not cover
We provide connectivity, hosting and observation. We do not provide assessment teams, logistics, or the programme design that turns a flood extent map into a distribution plan.
That boundary matters in this sector particularly, because the gap between “we can tell you where the water reached” and “we can run your response” is where a great many technology projects in humanitarian contexts have quietly failed. The data is genuinely useful. It is useful to an organisation that already knows what it would do differently once it had it.
Where to start
Name the locations you would need operational, the timeline, and what the programme has to be able to report. We will come back with what can be deployed, what can be observed from orbit instead of visited, and an honest account of what each option actually takes.
