Replacing spreadsheets and informal communication with a unified crew management system for 44 vessels and 2,000+ maritime crew

Maritime crew management · SpecTec Middle East · Nov 2023–Present · 3 applications, 11 React sub-projects, 44 vessels, 2,000+ crew

When the spreadsheet is the system, every change is a risk

Before this product existed, scheduling a crew rotation looked like this: open the rotation plan in ERP software, identify an employee, notice their certification is expiring mid-assignment, note it in a separate spreadsheet, contact a training vendor by email, wait for a response, update the spreadsheet when the vendor replies, and hope nothing changes in the interim that makes the note stale.

Activity scheduling lived in documents that only reflected reality if someone had remembered to update them. One operations manager's disciplined spreadsheet was another's undocumented tribal knowledge.

No system connected these steps. Compliance checking was manual. Vendor coordination was email.

I was asked to design a modern web layer on top of this legacy maritime ERP: three applications, eleven React sub-projects, a distributed team across Serbia, Dubai, and India. The brief described the technology. What it couldn't describe was how to turn a collection of manual, disconnected workflows into a unified system without losing the operational logic those workflows had accumulated over decades.

One system where five used to live

The Crew Planner needed to do what five disconnected tools had done separately: plan rotations, check compliance, schedule activities, coordinate vendors, and track documents. All in one place, all connected, all reflecting the same state.

The people using it weren't switching from a bad product. They were switching from habits. Operations staff who had spent years building personal systems (their spreadsheet, their email folders, their mental model of who needed what by when) were being asked to trust a single interface with work that had previously lived in their heads.

That constraint shaped every decision. The interface couldn't just be correct. It had to be legible enough that someone with fifteen years of spreadsheet-based muscle memory would trust it on day one.

Requirements describe intent. Interfaces have to describe every state.

The requirements for the Crew Planner were detailed. They described the intended workflows clearly: plan an assignment, schedule associated activities, send requests to vendors, track responses, issue documents.

What they couldn't describe, what no requirements document can describe, is what the product does at every combination of states that wasn't the happy path, especially when directly connected to a legacy system. That only becomes visible when someone has to decide what to show the user at each one.

The training activity edit flow is where this became most concrete.

The requirement said: allow operations staff to change activity dates before training is completed and certificates are issued. In practice, a training request can cover multiple crew members scheduled for the same certification.

The requirement was wrong to assume a training request is a single record with a single date. Each crew member has their own assignment, their own compliance windows, their own upcoming rotation. The request is a coordination artifact, a way of batching vendor communication. The activity belongs to the person.

The right unit of edit isn't the request. It's the person.

Treating the edit as a request-level action would have been the natural implementation. It would also have reproduced exactly the kind of ambiguity the product was supposed to eliminate: an operations user changing a date without knowing whether they'd changed it for one crew member or twelve.

The decision: editing an activity always happens at the person-assignment level. When a user initiates an edit, they enter a planning wizard scoped to that crew member's full assignment, not a single activity in isolation. This matters because activities are rarely independent.

Changing a training date often requires adjusting adjacent travel or medical activities to maintain compliance windows. The wizard surfaces the full picture for that person, so the user can make one coherent decision rather than a series of disconnected edits they'll need to manually reconcile later.

The consequences I had to resolve from that decision:

Activities with outstanding vendor responses get extracted from the group request on save.

The vendor responded to a group configuration that no longer exists. Keeping the activity in the original request would have left the system in a state that didn't reflect reality, exactly the problem Excel spreadsheets had. Extracted activities are queued for new requests. The vendor is notified of the change.

None of this was in the spec. The interface didn't just express these decisions, it's where the ambiguity the spec left open had to get resolved.

Consistency doesn't survive eleven repositories without infrastructure

The design system I built in Figma was the implementation reference for frontend teams across all eleven sub-projects. For a while, that was enough.

Then colleagues started building client demos that looked nothing like the product. AI-generated prototypes, given exact component specifications (radius values, font sizes, spacing tokens) produced interfaces that shared no visual DNA with what was in production.

A Figma file is a source of truth for designers. It isn't a source of truth for code.

The fix was to take the design system out of Figma and publish it somewhere code could consume directly. I drove the publication of the component library as an independent npm package with Storybook documentation: a single repository that any sub-project could include, that any colleague could reference for demos, and that any AI tool could be instructed to use as its actual component source.

This resulted in eleven codebases and a single source of truth. The same instinct that shaped the product decisions shaped how I thought about design infrastructure: go to the source, don't approximate.

44 vessels. 2,000+ crew. One system.