A commercial arrangement in which vessel owners place their ships under a single pool manager who markets and operates them together. Earnings from all voyages are combined and distributed to owners according to an agreed formula, so each owner's income depends on the pool's performance and their vessels' share of it.

Why build a progressive web app instead of native mobile apps?

The users were owners, operators, and managers on phones, tablets, and desktops, many of them at sea or in ports with poor connectivity. A PWA installs from the browser without an app store, runs from a single codebase, can keep working through a service worker when the connection drops, and updates on the next visit. That combination fit the requirement and the timeline.

How does real-time vessel tracking work in the application?

Position reports arrive from a vessel data feed, are validated and de-duplicated in a stream processing step, and update a last-known-state record per vessel. Changes are pushed to connected clients over a persistent connection, and the map renders from the current state rather than replaying a history on every load.

How is income analytics kept accurate and private?

Voyage results and pool distributions are computed from the pool's commercial source data, with a clear separation between accrued and settled figures. Every query is scoped to the requesting owner, so an owner sees the pool's overall performance and their own vessels' contribution, and nothing belonging to another owner.

What made a 90-day delivery possible?

A requirement stated in one sentence, an architecture chosen for the requirement rather than for ambition, a PWA that avoided parallel native builds, infrastructure as code from the first week, and a fixed set of scope decisions made in discovery and not reopened during the build.

Real-Time Maritime Analytics: How We Built a Ship Pooling PWA in 90 Days

Ship pooling is a business built on trust between vessel owners and a pool manager. Owners hand over commercial control of their ships, the manager operates them as a fleet, and income is shared out by formula. The owners' constant questions are the obvious ones: where are my vessels right now, and what am I earning. A pool manager came to us with those questions and a deadline, and we delivered a progressive web app that answered both in 90 days. This post covers the architecture and the decisions that made the timeline hold.

Key Takeaways

The requirement fit in a sentence: show each owner where their vessels are and what they are earning, in real time, on any device, for people who are often at sea with poor connectivity.
A progressive web app was the right form factor for a mixed audience of owners, operators, and managers on phones, tablets, and desktops, and it removed the cost of parallel native builds from the plan.
Real-time tracking is a state problem, not a streaming problem: validate and de-duplicate the feed, keep a last-known state per vessel, and push changes to clients.
Income analytics in a pool depends on getting the distribution model right and on scoping every query to the owner asking.
The 90-day delivery came from decisions made in discovery and not reopened: fixed scope, infrastructure as code from the first week, and an architecture sized for the requirement.

The requirement in one sentence

Good delivery timelines start with a requirement that can be stated plainly. Here it was: give every pool member a live view of their vessels and their income, on whatever device they have, wherever they are. Everything else in the project was derived from that sentence, and anything that could not be traced back to it was left out of the first release.

That discipline matters more in maritime than in most sectors, because the domain is deep and the temptation to build a full operations platform is strong. Voyage planning, chartering, bunkering, and crew management all touch the same data. We scoped the first release to answer the owners' questions and nothing else, so that later releases would extend from a working base rather than a partial one.

Why a PWA

The audience was mixed in a way that decides the form factor for you. Vessel owners are typically business people who check on their fleet from a phone. Pool operations staff work from desktops. Ship managers and superintendents move between the office, the port, and the vessel, often with a tablet and intermittent connectivity.

Native applications would have meant separate builds for each platform, app store review cycles, and a desktop web application on top. A progressive web app gave us a single codebase that installs to the home screen from the browser, opens full screen like a native app, updates itself on the next visit, and can keep working through a service worker when connectivity drops. For a fixed timeline it was the difference between building the product once and building it several times.

Connectivity is the constraint to design for. People at sea and in ports lose it for long stretches, so the pattern for a PWA of this shape is to cache the shell, the last-known vessel state, and the most recent analytics, show the last view with a clear indication of how stale it is when there is no connection, and refresh when the connection returns.

Architecture

The system has a small number of parts, each with a clear job.

[Vessel position feed] ---> [Ingest + validate + de-dup] ---> [Vessel state store]
                                                                    |
[Voyage + pool finance data] ---> [Analytics jobs] ---> [Analytics store]
                                                                    |
                              [API layer: auth, owner scoping, queries] <---+
                                        |                    |
                              [Realtime push channel]   [REST endpoints]
                                        |                    |
                              [PWA: service worker, cache, map, charts]

The position feed is the external input. It is noisy: reports arrive out of order, duplicate, and occasionally with impossible values. The ingest step validates each report, discards duplicates and outliers, and updates a single current-state record per vessel. That record is what the rest of the system reads. Clients never consume the raw feed.

Voyage results and pool finance data come from the pool manager's commercial systems on a schedule. Analytics jobs compute the figures each owner needs to see and write them to a store designed for the queries the interface makes. The API layer authenticates users, resolves which vessels and figures each user may see, and serves both a request-response interface and a persistent push channel for live updates.

The PWA is deliberately thin. It renders the map and the charts from state it receives, keeps a cached copy of its last state, and does no business logic of its own. Keeping computation on the server meant the client could stay fast on older phones and meant every figure an owner saw was computed in one place.

Real-time vessel tracking

The instinct with real-time tracking is to think of it as a streaming problem, and to design a pipeline that replays every position to every client. That is more infrastructure than the requirement needs and it makes the client responsible for reconstructing state.

We treated it as a state problem. Each vessel has a current position, heading, speed, status, and timestamp. The ingest step updates that state and emits a change event. Connected clients subscribe to the vessels they are entitled to see and receive change events over a persistent connection, applying them to the state they already hold. A client that connects fresh, or reconnects after losing its connection, fetches current state once and then resumes receiving changes.

This design has practical benefits beyond simplicity. Clients on poor connections receive small change events instead of full snapshots. The server can coalesce rapid updates. And the map renders from a single consistent state, so a vessel never appears in two places or jumps backwards because a delayed report arrived late.

The map itself renders vessel markers, tracks for a recent window, and status. Owners can select a vessel for detail, and operations staff see the fleet. The same components serve both, differing only in the scope the API returns.

Income analytics for a pool

The analytics side is where domain understanding mattered most. In a pool, an owner's income is not the earnings of their vessel. It is their share of the pool's combined result, determined by a distribution formula that weights each vessel's contribution. Owners want to see the pool's performance, their vessels' contribution to it, and their resulting share, and they want to understand the difference between what has been accrued for voyages still in progress and what has been settled.

We modeled the distribution explicitly rather than presenting raw voyage figures, so that the number an owner sees on their phone is the number the pool manager will settle on. Accrued and settled figures are kept distinct throughout, labeled as such in the interface, and reconciled when settlement runs. Charts show performance over time, per vessel and per owner, with the same scoping rules as tracking: an owner sees their own vessels and the pool aggregate, and no other owner's detail.

Because these are financial figures that owners will act on, the analytics jobs are deterministic, versioned, and re-runnable. If an input is corrected upstream, the affected periods are recomputed and the change is visible in the history. That auditability is a requirement in any pooling arrangement, and it is the kind of thing that is cheap to design in and very expensive to add later.

The 90-day plan

The timeline held because the plan was built around decisions, not around hope. In outline:

Discovery and design. The requirement was written down in the sentence above. We agreed the scope of the first release, identified the vessel data feed and the commercial data sources, confirmed how owners and staff would authenticate, drew the architecture, and set up the cloud environment and delivery pipeline as infrastructure as code. Nothing in this phase produced a screen, and it was the most important phase in the project.

Build. Ingest and vessel state came first, because everything downstream depended on them and because the feed's quirks needed to be understood early. The PWA shell, authentication, and the map followed, giving the client a working tracking view to react to well before the end. Analytics jobs and the income views came next. Caching and the service worker belong alongside the build rather than at the end.

Hardening and launch. For an application of this shape, hardening means testing load and reconnection behavior against simulated feed disruption, testing owner scoping by attempting to reach data across owners, confirming monitoring, alerting, and backup, and releasing to a small group of owners before the full membership so support can respond to early feedback.

Two habits made the biggest difference. Scope decisions from discovery were not reopened during the build; new ideas went into a list for the next release. And the environment was reproducible from a repository from the first week, so there was never a gap between what ran in staging and what would run in production.

Infrastructure and operations

A real-time application that owners check daily has to stay up, and it has to stay up when the position feed or a commercial data source misbehaves. The application runs on cloud infrastructure designed with monitoring on the feed, the ingest path, the push channel, and the API, so a stalled feed is noticed before an owner notices a stale map.

This is where our background matters. BeyondScale began as an infrastructure company and has run production environments for clients ever since, and the maritime application was designed the way we design any production workload: identity, network, backup, and recovery decided up front, and operations handed to a team that expects to be paged. Our cloud infrastructure practice covers that side of the work.

What we would tell another maritime team

If you are considering a similar build, the lessons transfer.

Write the requirement in a sentence and derive the scope from it. Maritime data is deep enough to absorb any budget; the sentence keeps you honest.
Choose the form factor for the audience you actually have. A mixed audience with connectivity problems is a strong argument for a PWA.
Treat tracking as state, not stream. Validate and de-duplicate once, keep current state, push changes.
Model the money the way it is settled. Owners will compare the app to their statements, and the app has to match.
Scope every query to the requester, and test it by trying to break it.
Put infrastructure as code and monitoring in the first week, not the last.

Our DevOps and application delivery practice runs the assessment phase where these decisions get made, and the same team carries them through build and operations. If you have a fleet, a pool, or a maritime data problem and a deadline, get in touch and we will start with the sentence.