Our First
Implementation.

Every platform has a moment where the theory meets a real operation for the first time. This is ours.

Our first client runs a container freight business. On paper, they looked straightforward: they move cargo, they have vessels, they have clients, they invoice for shipments. All things the platform was built to handle.

In practice, almost nothing about how they worked matched the standard booking flow.

How their operation actually ran

Their corporate clients did not book through a portal or fill in a form. They sent orders over WhatsApp. Those orders referenced liner codes their clients already knew and expected to see on every document. The vessels involved were not simple point-to-point ships but tugboat-barge combinations, where a single job might split across two vessel types that the system needed to treat as one operation. And their team, the people actually processing all of this, lived in spreadsheets. That was not a gap to be patched. That was just how their business worked.

When they came to us, we had two options. We could ask them to change how they operated to fit the platform. Or we could build the platform to fit how they operated.

We did not ask them to change.

What we built

The B2B orders module exists because of this client. It is a corporate order flow that handles bookings which do not follow the standard path: orders that arrive outside the normal channel, reference codes the client controls rather than the operator, vessel configurations that standard shipment logic does not account for, and document outputs that match what the corporate client expects to receive, not just what the platform would produce by default. We wrote up exactly how that module works in detail on its own page, if you want the deeper version.

None of that was on the original roadmap. All of it came directly from sitting with one real operation and understanding exactly where the friction was, before writing a single line of code.

When your workflow does not fit the manual, we build the module.

Why it now ships with every installation

Once the module existed, something became clear: the problem it solved was not unique to this one client. The specifics were theirs. The underlying shape of the problem was not.

Corporate clients behaving differently from retail clients is not unusual in maritime freight. It is common. The expectation that a single booking flow can handle both, without bending either side to fit the other, turns out to be optimistic. The operators who handle corporate accounts know this already. They have been managing the mismatch manually, in spreadsheets and email threads and separate processes that nobody documented, because the software they had did not have a better answer.

B2B orders is that answer. It ships with every SEALUTION installation now, not because every operator will use it immediately, but because the operators who need it should not have to ask for it or wait for it. It should just be there.

What this says about how the platform grows

We say on the homepage that your operation teaches the platform. This is what that means in practice. A real client brought a real problem. We built the solution to fit their operation, not the other way around. The solution turned out to be useful beyond them. It became part of the platform every new client receives.

That is the cycle. Not a roadmap drawn in advance and delivered on a schedule, but a platform that gets more capable as real operators use it and real gaps become real features.

The first implementation is where that cycle started. Every installation since has carried something that came from it.