Every maritime software vendor claims to "support compliance." Most of them mean a PDF folder and a date column. The difference between that and software that actually keeps an operation audit-ready is not a feature — it is an architectural decision made on day one. We call it compliance by design, and it is the first pillar of everything we build.
The bolt-on trap
The typical lifecycle of a compliance module goes like this: a product is built to manage operations, a client fails an inspection, and a "compliance tab" is added in a sprint. The result is a parallel bookkeeping system — the software says one thing, the regulation requires another, and a human is left to reconcile them in a spreadsheet.
The failure is structural. Regulations like STCW (as amended by Manila 2010) and MLC 2006 are not lists of documents; they are systems of rules that depend on rank, department, vessel type, flag state and time. A bosun and a second engineer do not carry the same certificates. A certificate valid under one flag may require an endorsement under another. A medical certificate has a different validity cycle than a Certificate of Competency. If your data model does not know these distinctions, no amount of UI can fix it.
What "designed-in" actually looks like
In practice, compliance by design means the regulatory logic lives at the data layer and everything else is derived from it:
- Requirements are rank-scoped. The system knows which document set applies to each rank and fleet category — deck versus engine, merchant versus offshore — instead of one generic checklist for everyone.
- Expiry is a computed state, not a stored one. "Valid", "expiring" and "expired" are calculated continuously from issue dates, validity cycles and configurable warning windows — never typed in by hand.
- Verification leaves a trail. Who verified a document, when, against which registry, and with what outcome, is recorded as first-class data. An auditor should be able to reconstruct every decision.
- The catalog is data, not code. When a flag administration updates a requirement, the rule catalog changes — not the source code. Regulation moves faster than release cycles.
| Question | Bolt-on compliance | Compliance by design |
|---|---|---|
| Who knows which documents a rank requires? | The user, from memory | The data model |
| What happens when a rule changes? | A new release, eventually | A catalog update |
| Can you prove who verified what? | Sometimes, in email | Always, in the audit trail |
| When do you learn about an expired certificate? | At the inspection | Thirty days before |
Why this matters commercially, not just technically
In regulated industries, software is only as valuable as its worst audit. A crewing operation that discovers an expired certificate during a port state control inspection does not care how elegant the dashboard was. Systems designed around the regulation convert compliance from a recurring emergency into a background process — and that is a measurable operational cost, not an abstraction: fewer detentions, fewer last-minute crew changes, fewer contracts lost to paperwork.
Panama is home to the world's largest ship registry, and the gap between regulatory expectation and operational tooling here is enormous. That gap is precisely where we work.
Key takeaways
- Compliance added after the fact always becomes parallel bookkeeping.
- STCW/MLC are rule systems — rank, flag, time — not document lists.
- Expiry states must be computed, verification must leave a trail, rules must live in data.
- The commercial value of compliance software is measured at the audit, not the demo.
Working in a regulated industry and wrestling with the problems described here? We build software for exactly this.
Talk to PBS