Custom vessel tracking software development
A ship broadcasts its position every few seconds, but the question on shore is different: when will it be alongside, and what does that mean for tomorrow's planning? Between that AIS message and a usable answer lie processing, storage, an arrival estimate that keeps shifting, and coverage that has gaps at sea. Appfront builds software that turns vessel positions into decisions, for shipowners, charterers, agents, terminals and shippers who plan around an arrival.
What makes tracking a ship different
Tracking a van is a solved problem: an onboard unit or phone with mobile coverage, a position every few seconds, a route over a road network mapped to the metre, and an arrival estimate within the same service. Tracking a sea-going vessel looks superficially similar and is, in practice, a different discipline. The position comes from a broadcast over the VHF band, picked up by receivers on shore or by satellites, with all the interruptions that entails. The route runs over water, not a network of junctions and bends. And the arrival lies so far ahead that the estimate shifts dozens of times on the way, while on shore pilots, tugs, cranes, staff and lorries are already committed to it.
On top of that, the operation itself is split across parties who cannot see into each other's systems. The shipowner knows what the vessel is doing, the agent arranges the call, the terminal determines the berth and the window, customs wants the data in advance, and the shipper only wants to know whether their cargo is feasible. Vessel tracking software is therefore rarely just a map. It is the layer that turns a stream of raw positions into a shared picture on which several parties can each make their own decision.
Are you in the right place? This page is about sailing, not building. If your question concerns the shipyard, sections and fittings, engineering, or the build file for a vessel not yet in service, you want shipbuilding software. There, the ship is the product being created; here, the ship is a moving point with cargo, paperwork and an arrival time.
The position is public
AIS is a broadcast, not a private channel. Anyone with a receiver can see your vessel. What you need to protect is not the position itself, but what people can conclude from it.
The message is not the truth
Destination, draught and estimated time of arrival are entered by hand. They reflect intent, not measurement, and sometimes still carry over from the previous voyage.
One arrival affects ten parties
Pilotage, towage, berth, crane, crew, transport and customs declaration all hinge on the same moment. If that shifts, the entire chain shifts with it.
Processing AIS: from message to usable position
AIS stands for Automatic Identification System and works like a broadcast over two fixed VHF channels. A transponder on board transmits its position, course and speed at regular intervals, and any receiver within range picks it up. Seagoing vessels above a certain size and all passenger ships are required under the International Convention for the Safety of Life at Sea to carry and operate such a transponder. Smaller craft use a lighter class that transmits less often and at lower power. You should know this difference, because it determines how often you can expect a new position and therefore when silence signals a fault.
The messages come in types. A position report contains the core: coordinates, course over ground, speed over ground, heading and rate of turn, plus a timestamp and an indication of the accuracy of the position fix. A static report contains the identity and hull: name, call sign, vessel type and dimensions. A third category contains voyage data: destination, draught, persons on board and estimated time of arrival. That last group is entered by hand. This makes the separation clear: the dynamic fields are measurements, the voyage fields are intentions, and a system that stores the two together produces unreliable planning.
Identity: the number you attach the history to
A vessel has several numbers and they do not serve the same purpose. The number the transponder announces itself with belongs to the radio licence and the flag; it changes when the ship changes flag or owner, and it is reissued after deregistration. The International Maritime Organization ship identification number belongs to the hull and stays the same for the vessel's entire life, including after renaming and re-registration. If you attach your voyage history to the radio number, you lose a ship's past the moment it reflags, and you may one day inherit the history of a different vessel that was given the same number. The practical solution is a dedicated vessel entity with a validity window per identifier, so that a past position stays with the ship that transmitted it at the time.
Names are even less reliable. They are mistyped, appear in capitals with or without prefixes, and recur across multiple vessels. So never match on name, not even in an integration with a terminal or a freight forwarder. Record an explicit mapping between your own vessel entity and the number the counterparty uses, manage that mapping in the system rather than in a spreadsheet, and log whichever assumption was made when a message could match more than one vessel.
Storing data without the stream overwhelming you
Tracking a fleet means storing a continuous stream of small messages, and there are three pitfalls that only take their toll over time. The first is duplication: the same transmission arrives via several receivers and sometimes via several providers. Without deduplication on vessel identity and measurement timestamp, your archive grows faster than necessary and every count becomes unreliable. The second is ordering. Messages do not arrive in the order they were sent: a satellite reception may come in later than a position picked up from shore afterwards. If you take the most recently received record as the current position, vessels will visibly appear to sail backwards. The latest position is the latest by measurement time, not by processing time, and that is a decision in the data model, not a detail of the display.
The third pitfall is wanting to keep everything forever in the same form. That does not work, and it is not necessary either. Raw messages are valuable for a limited period, for investigating faults and for recalculating events. For history, a simplified track is sufficient: line simplification keeps the shape of the voyage intact with a fraction of the points. Store the derived events separately as well, because they are the answers to the questions asked later. A common setup is a time-series store with a spatial index, with the raw stream in a separate layer and an increasing retention period per layer: fine-grained and short-lived for raw data, coarse and long-lived for history.
On the read side, the same problem applies in reverse. A map showing an entire fleet is tempting to populate directly from the position table, and that works only for as long as the test setup is small. As the fleet grows and the history lengthens, the map should be served from aggregated data: summarised points per zoom level, grouping where vessels lie close together, and a track that is delivered in steps rather than all at once. The question itself also changes per user. A planner wants the latest status of ten vessels, an analyst wants three voyages side by side, and a customer portal wants one vessel without the rest. These are three different read paths, and it is wise to build them as three paths, with a separate view table for the current status alongside the archive. Finally, do not rely on the browser as the place where you filter: what the user is not allowed to see should not be sent to them in the first place.
There are coverage gaps at sea
This is the point where demonstrations look better than reality. Reception from shore is limited to the line of sight of the VHF link, so to a few dozen miles of coast. Beyond that you depend on satellite reception, which has two characteristics you must build in: there is a time gap between two passes, and in busy areas the transmissions of many vessels overlap to such an extent that some cannot be read. In addition, a transponder may be switched off, may be jammed, or may report a position derived from a disturbed satellite navigation signal. The result is a track with gaps, with jumps, and sometimes with a position in the middle of the land.
What makes a system responsible here is not making the data look better but being honest about it. That means recording for each position where it comes from and how old it is, and keeping that age visible wherever someone makes a decision. It means plausibility checks: a jump that would require an impossible speed, a position on land outside a waterway, a heading that does not match the track. Such observations are flagged and kept aside rather than quietly discarded, because a run of anomalies is itself a signal. And it means interpolating between two measurements on the last known course and speed, provided those intermediate values are clearly shown as estimates and never end up in the archive as measurements. Finally, set an expected interval per source and report when a vessel stays away longer than that interval allows, since that is precisely what a planner needs to know.
What a vessel tracking system needs to be able to do
These components are connected. An arrival estimate without a source record is indefensible, geofences without a trip definition produce isolated events, and an integration without unambiguous vessel identification shifts the error onto the recipient.
Position processing with provenance
Deduplicate, sort by measurement timestamp, and record for each position where it comes from, how old it is, and whether it is measured or estimated.
Identity with a timeline
One vessel entity with a validity window per number, so that reflagging and renaming do not break the voyage history.
Arrival estimate with a margin
An estimate of the route over water, with an uncertainty band, a source and a timestamp, instead of a single hard figure.
Geofences that generate events
Port boundary, anchorage and berth as areas that report entry, stay and exit, with thresholds against boundary flickering.
Voyage file per trip
Track, events, documents and consumption under one voyage number, with a fixed definition of where a voyage begins and ends.
Integrations that can withstand failure
Exchange with planning, terminal and customs using repeatable messages, correlation keys and a queue for what did not arrive.
Calculating the arrival estimate and keeping it up to date
The first mistake is the simplest: take the straight-line distance and divide by the speed. That sends a ship across land, ignores canals, locks, straits and traffic separation schemes, and yields a result that is too early in almost every basin. A usable calculation measures the remaining distance along a navigable route, with the known passages as nodes. This immediately sharpens the question: which route is this vessel taking, and what happens to the estimate if it chooses a different one en route?
The second mistake lies in the speed. The last measured speed over ground jumps with every wave and every course correction, and on a river or in a current it says something different from the speed through the water. Projecting the last measurement forward to an arrival produces an estimate that shifts with each message and thereby loses its credibility. More useful is a smoothed speed over a window, distinguishing sea passage from manoeuvring, with a correction for the fixed delays every approach involves.
The third and most important mistake is treating arrival as a single moment. In reality there are at least three: reaching the port boundary, arriving at the berth, and the moment the vessel is made fast and handling can begin. In between lie waiting for an anchorage, a tidal window for access with a draught restriction, availability of pilot and tug, and a berth that is still occupied. The planner ashore benefits most at the last moment, and precisely that cannot be derived from AIS. It follows from your own model plus what the port and the terminal tell you.
Useful as it is to ask why a ship deviates from its estimate: wind, wave height and current separate speed over the ground from speed through the water, and against a head current or in rough weather the same engine speed produces different progress. But not every delay is a loss: a ship that knows its berth is still occupied may deliberately slow down rather than wait at anchor, and that is a decision, not a hold-up. For the shore side this makes a difference, because in one case the arrival shifts and in the other the arrival is deliberately aimed at an agreed window. A system that keeps the reason alongside the estimate changes the conversation: not whether it will be late, but what is still open to choose.
Multiple sources, one estimate
In practice, several estimates for the same vessel circulate side by side: the manually entered field in the AIS message, the agent's notification, the master's message, the calculation from your own model and the window the terminal has scheduled. They contradict one another, and that is normal. The work lies in bringing them together: record for each estimate who issued it, when, and on what basis, choose a priority rule that can be explained, and show which source is currently leading. A system that displays a single figure without its provenance will be ignored at the first conflict.
Also keep every estimate you have ever issued. Only in this way can you measure the error afterwards: how far off you were at a one-day horizon, and how far at a half-day horizon, per route and per vessel type. That error curve is the only honest evidence that your model is better than a practised judgement. It is also the basis for a margin rather than a point figure, and a planner who knows the margin plans differently. See also custom planning and scheduling software development if the emphasis lies on the scheduling itself.
Finally: a shift is only news if something can be done about it. So do not report every adjustment, but the adjustment that crosses a threshold meaningful to the recipient: a shift change, a terminal window, a booked loading time, the point at which transport can still be rebooked. Without those thresholds the result is predictable: everyone switches the notifications off and no one looks any more.
- Distance along a navigable route, not as the crow flies
- Speed smoothed over a window
- Port boundary, berth and making fast named separately
- Tide, pilot, tug and berth occupancy taken into account
- For each estimate a source, a timestamp and a sender
- Explainable priority when estimates conflict
- Every issued estimate retained to measure the error
- Notifying only at planning-relevant thresholds
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Geofences, port approach and the voyage file
A geofence is nothing more than an area on the map to which the system responds: a port area, an anchorage, a berth, a canal section, an emission zone, an area you want to watch for insurance or sanctions reasons. As soon as a track enters or leaves that area, an event occurs. That is the idea, and in practice it is more difficult than it sounds, for three reasons.
The first is that a ship can linger on a boundary. A tug working along the edge of a port area, or a vessel that drops anchor just outside the line, then produces a string of entries and exits that mean nothing. The fix is not a stricter boundary but a threshold: a minimum dwell time before an entry counts, a margin between the boundary for entering and the one for leaving, and a maximum number of transitions per period. The second is that zones sit inside one another. A berth sits within a terminal, which sits within a port area. Events should follow that nesting, so that an arrival at the berth is not detached from the arrival in the port, and a report does not count the same movement twice. The third is the quality of the zones themselves. Official port boundaries and berth boundaries are a different thing from a hand-drawn box, and the difference returns sooner or later as a dispute over who was late.
The port call as a sequence of events
A port call is not a state but a chain: arrival at the port boundary, anchoring and weighing anchor, pilot on board, first line, made fast, start and end of the operation, last line, departure. Some of these moments can be derived from position data with reasonable confidence, for example by combining speed below a threshold inside a berth zone with a dwell time. Others cannot, and come only from a message from the agent, the terminal or the port authority. Record for each event how it came about: derived, reported or set by hand. That distinction is exactly what you need when a invoice or a claim later depends on it.
International agreements are pushing this exchange towards a single digital window per port, where notification of the vessel and the data on cargo and crew are submitted electronically rather than by form. In the Netherlands this runs through the national window and through the port community systems that pass notifications on to authorities and terminals. For your own system this rarely means you make the declaration yourself, but it does mean having the right data ready at the right moment and being able to show when it was ready. You can read more about the systems around the port call under port software development.
Voyage records and sailing history that survive a question afterwards
A voyage is not a technical fact but an agreement. Does a voyage run from departure berth to arrival berth, per charter, per cargo, or per set of ports that together form one round trip? Each choice can be defended, but one choice must be fixed and applied uniformly everywhere, otherwise the figures in two reports will never match again. Around that voyage you hang the track, the events, the revised estimates, the documents, the port costs and the consumption. In this way a voyage record becomes something other than an archive: it is the place where a later question gets answered.
Those questions do come. Why was this vessel later than notified? Was the waiting time rightly charged on? Where was the ship at a given moment? Which route ran through which area, and does that match what the transport documents say? The reporting on fuel consumption and emissions under European rules also works per voyage and distinguishes between the ports involved in a route, so the way you delimit voyages is no longer a cosmetic choice. Whoever sets this up only afterwards may recalculate the history with zones and rules that have since changed.
Three design rules follow from this. Record events as immutable, with source and measurement time, and correct by adding a new event rather than overwriting the old one. Keep with every derived event the version of the zone and of the rule that produced it, so that a redrawn geofence does not rewrite history. And separate measurement from interpretation in the model, so that you can improve your rules without losing your measurements.
Integrating with planning, terminal and customs
The value of vessel tracking lies not in the map but in the handover. A position that only sits on a screen changes nothing; an arrival estimate that lands automatically in transport planning changes a planner's day. On the landside, that usually means three directions. The first is your own planning, whether that is a transport management system, an order package or your own board. See building a TMS if that side is still missing, and a track and trace system if the customer needs to be able to follow along themselves.
The second direction is the terminal and the hinterland. That covers berth planning, windows for loading and unloading cargo, and booking time slots for road transport. A shifting arrival is only properly handled once the related slot shifts with it, and that requires an integration that not only reads but also changes data and returns a confirmation. How such a booking flow works is described in the slot booking portal.
The third direction is customs declaration. Cargo details must be known before arrival, and the pre-notification and manifest hang on the same arrival moment you are tracking. Your system is rarely where the declaration is made, but it is the place that knows when each piece of data became available and which change came afterwards. For that side, customs clearance automation is the adjacent building block.
Technically, these integrations run across two worlds. In one, structured messages are exchanged under standards that have been in use for decades; in the other, it's web interfaces with tokens and event streams. Both demand the same foundation: messages sent twice must not cause a double booking, a correlation identifier must keep request and response together, there must be a queue with retries, and a place where failed messages stay visible instead of disappearing. The hardest part, however, is not the technology but master data: your vessel list, the terminal's and the customs declaration's must be explicitly mapped to one another, maintained in the system and not in the head of a single employee.
When an existing platform is enough
Being honest about the limits of custom is part of this. There are mature providers of AIS data and tracking platforms with worldwide coverage, satellite reception, port call data and ready-made map layers. Building the reception yourself is a bad idea for almost everyone: you buy that data in. And if you mainly want to view, filter, track a fleet and receive a notification when something happens, a subscription to such a platform is the wiser route, and we would rather tell you that now than halfway through a project.
Custom starts to pay off once the decision logic is yours. That is the case when you need to combine multiple sources into one accountable expectation, when your voyage definition and reporting obligations do not fit a platform's model, when the history must be kept in your own environment because claims and accountability depend on it, or when the position only becomes valuable in combination with your orders, contracts and agreements. Often the best form is a combination: buy in data and coverage, and build the layer that turns it into decisions yourself. If your question goes beyond position and arrival, custom maritime software is the broader entry point, and for the chain beyond the port, supply chain management software.
That choice comes with one practical warning. Read the licence terms of your data source before you set up an archive. Storage, onward sharing and making data visible to third parties are all covered there, and the outcome partly determines how you arrange storage and rights. If you build it yourself, keeping track of changing regulations and message formats is the responsibility of your own organisation.
- Buying in data and coverage, building the logic yourself
- When the question is to view, filter and report: platform
- Custom development when you have your own expectation across multiple sources
- Custom development when history must be kept in your own environment
- Link on identification, never on vessel name
- Repeatable messages, with a queue and visible failures
- Master data displayed and managed in the system
- Licence terms of the data source read first
Frequently asked questions about vessel tracking software
Because that ETA is entered by hand, as are the destination and the draught. The field only changes when someone on board updates it, and it often contains an abbreviation, a port code or still the value from the previous voyage. Read it as an intention, not a planning figure, and calculate your own arrival estimate from position, course, speed and the route over water.
It shows the difference between a measured and an estimated position. Reception from shore reaches as far as the horizon of the VHF link, satellite reception has repeat intervals, and in busy areas messages overlap. A responsible system therefore shows how old the last measurement is, interpolates between two measurements based on course and speed, marks those intermediate values as estimates, and raises an alert once a vessel stays away longer than its source allows.
That depends on the licence, and that question should be on the table from the outset. Commercial data sources impose conditions on storing, passing on and making data visible to third parties, and those conditions partly determine how you set up your archive. Also be mindful of positions of small vessels: once a position can be linked to a person, data protection comes into play and a purpose and a retention period should be fixed.
No. Shipbuilding software supports construction: sections, engineering, fittings and the build file of a vessel that is not yet sailing. This page is about operating a vessel that is already at sea: where it is, when it arrives and what that means for planning ashore. If you are looking for the shipyard, the page on shipbuilding software is the right entry point.
Often, for viewing, filtering and alerting. Mature providers of AIS data and tracking platforms with worldwide coverage, satellite reception and port call data exist, and rebuilding reception yourself rarely pays off. Custom development becomes worthwhile once the decision logic is yours: your own arrival estimate across multiple sources, your own voyage definition, or history that must sit in your own systems for claims and accountability.
The source code and documentation belong to the client and sit in a repository to which you have access yourself. On handover, a description of the architecture, the data models, the integrations and the deployment is included, so another party can take over without first having to reverse-engineer anything. We work with mainstream technology, because that determines how many parties can take on the maintenance.
Related services
Shipbuilding software
If you are looking not for the operation but for the shipyard, with sections, engineering, fittings and the build file of a vessel that is not yet sailing, then shipbuilding software is the right entry point. There the vessel is the product; here it is a moving point with cargo and an arrival time.
Custom maritime software
If the question is broader than position and arrival, covering maintenance, certificates, crewing, charters or per-voyage invoicing, then custom maritime software is the wider starting point, with vessel tracking as one of its components.
Port, terminal and what follows
For the approach and handling in the port itself: port software development. For scheduling transport around an arrival, get a TMS built, and for customers to follow along, a track and trace system.
From AIS message to berth planning
Tell us which data sources you use today, how the arrival estimate reaches your planner and what happens when a vessel drops out of coverage. Those three answers usually show whether you need to buy data, build logic, or both.