Details in this account are generalised and figures are omitted where they would identify the client.
The situation
A working harbour with a mix of commercial traffic, fishing vessels, annual moorings and visiting leisure craft.
Operations ran on a whiteboard for current berths, a card index for annual mooring holders, a spreadsheet for dues, and the harbourmaster's knowledge for everything else. Compliance records were in files.
It worked, and it depended entirely on continuity of staff. The trigger was an audit that asked for records that took two days to assemble.
What we got wrong first
Worth putting first because it was the most instructive part of the project.
Our initial design treated berth allocation as a booking problem: a grid of berths against time, with vessels dragged into slots. It demonstrated well and the harbourmaster disliked it immediately.
The reason took a while to surface. A berth allocation is not a booking. It is a judgement made with incomplete information — the vessel's actual draught rather than its declared one, the state of the tide, the weather forecast, what might come in unexpectedly, whether the fishing fleet is due back, and which skipper can be asked to move at short notice.
A grid implied a certainty that does not exist, and it removed the flexibility that the whiteboard provided. Worse, it invited the system to suggest allocations, which the harbourmaster correctly regarded as presumptuous.
What replaced it was much less clever: a clear view of what is where, what is expected, and what each berth can physically accept — with the system preventing impossible allocations and saying nothing about preferable ones.
The software's job was to prevent mistakes and show the picture. The judgement stayed with the person who had it. Getting that boundary wrong nearly lost the project.
What we built
Vessels as the central record, with dimensions, draught and type, and the parties associated with each — owner, skipper, agent — as separate roles rather than one customer field.
Berths with their physical constraints, so an allocation exceeding length, beam or available depth is refused with a reason.
Movements recorded on a phone, on the quay, offline, in seconds. This was the requirement that most shaped the interface, and it was the one we tested most.
The dues tariff encoded, so charges are calculated from movements rather than worked out. This was the clearest financial return: charging became consistent, and some categories that had been applied inconsistently were applied properly.
Moorings and the waiting list, with position, dates and history. The waiting list in particular had been a source of disputes, and having a dated record settled them.
Compliance and inspection records attached to the relevant asset, with dates and attribution, and reminders before expiry.
What made adoption work
Two things.
The first thing it did was save the harbourmaster time, not produce a report for the board. Recording a visitor arrival on a phone on the pontoon was faster than writing it on a pad and entering it later, and that was demonstrated on day one.
The whiteboard stayed for two months. Both were maintained in parallel, and the whiteboard came down only when everybody had stopped looking at it. Removing it early would have created resistance that took much longer to overcome.
The offline requirement
Signal around the harbour is patchy — worse among structures, inside buildings and at the far end of the pontoons.
Movements are recorded locally and sync when a connection is available. The interface shows clearly what is pending, so nobody wonders whether something was recorded.
This was not a refinement. Without it the system would have been abandoned in the first fortnight, for the reasons in maritime IT explained.
What we would do differently
Watch the work before designing anything. A morning on the quay before the first design session would have prevented the berth grid entirely.
Take the tariff encoding first. It delivered the clearest return and could have been released before anything else, funding confidence for the rest.
Plan the historical data properly. Bringing years of mooring history across from cards and spreadsheets took longer than expected, and some of it we ultimately archived rather than migrated.
The general lessons
Where a system meets professional judgement, the system should prevent errors and present information. It should not decide.
Design for the person outdoors with a phone, not the person at the desk.
Encode the charging rules first. It is usually where the return is clearest and the scope is most contained.
Our team combines maritime background with business systems work — see systems for ports and harbours. Start a conversation.