A matte steel workbench in a cool-lit Liège software workshop, wire spools and grid paper under overcast morning light.

Rue de la Loi 155 · 1040 Brussels — a working morning at the bench

Custom software, cloud, data, and integration

Berths that hold, systems that ship.

Six service lines

One bench, six trades — and you are not asked to take all of them

Bluehaven Maritime Services BV delivers six service lines, and most clients start with one and grow into two or three. They are not sold as a bundle.

Each has its own scoping questions, its own timeline shape, and its own way of going wrong. This page explains what each one actually involves, in the order a client usually meets them.

Delivery

Delivery you can open every two weeks

Iterative work — something you can open, click, and comment on from the first sprint, rather than a specification that grows for six months.

Hands patching a port on a matte steel patch panel in a cool-lit industrial wire room, ordered cable runs behind.
Build — rails, connectors and reconciliation trails.
A cold datacentre aisle with cable trays receding into pale grey and one distant human silhouette.
Run — where the batch window stops deciding your day.
Stacked container rows at a Belgian quay under pale overcast light, one gantry leg crossing the frame.
Hand over — the operation keeps running while we work.

What we do

The six service lines, in the words of the work

Each line has a different scoping conversation. Read the one that matches the problem you are carrying right now — the rest can wait.

Custom software development

Built with the people who run the process

This is the core of what we do. A client has a process that runs on spreadsheets, a legacy desktop tool, or an ERP module that was never meant for the job, and needs something built for it.

Work starts with the people who use the process daily, because that is where the undocumented rules live. We build web applications, internal tools, and customer-facing portals, typically in modern stacks with automated tests and a deployment pipeline from the first sprint.

What a first phase looks like

  • A working session with the delivery and operations leads, in your building or online.
  • A short written scope naming what is in, what is not, and the decision each item needs.
  • Something clickable every two weeks, tested, deployed to a staging URL of your own.
Ask about a specific service

Cloud consulting and migration

The easy part is the move

Moving to cloud is rarely the hard part. The hard part is the application that assumed a fixed server, a local file share, and a nightly batch window.

We assess what you run, classify it by how easily it moves, and plan the sequence: lift-and-shift where it makes sense, refactor where cloud capabilities actually change the economics, and leave alone what genuinely works better where it is.

Belgian clients also ask about data residency, and the answer depends on the workload, so we map that before choosing a region. Cost modelling is part of the assessment, not a surprise in month three.

Three ways a workload is treated

Lift and shift
A workload with no reason to change. It moves, it keeps running, and nobody rewrites an unbroken business rule to please a rumour.
Refactor for economics
Where managed services actually change the cost curve — storage, batch, messaging — and the rewrite pays for itself on the bill.
Leave where it belongs
Late-life systems that still hold a business together. We name them, hand over the reasoning in writing, and move on.

Data, BI, and AI

One number per question

Maritime and industrial companies sit on decades of operational records: voyage logs, container movements, maintenance histories, energy readings. The first job is almost always to get those into one place with agreed definitions, because two departments reporting different numbers for the same thing is a governance problem, not a database problem.

From there, dashboards, scheduled reports, and self-service queries replace the manual rebuilds. Where the data supports it, we move into forecasting and anomaly detection on equipment and vessel signals. We are honest about which projects stop at the warehouse, because many should.

Where a project usually stops

A governed warehouse with agreed definitions, one dashboard the operations team actually opens, and a monthly extract nobody has to rebuild by hand.

Where forecasting earns its place

When there is a real history, a repeatable signal, and a person who will act on the output — not when the board has asked about AI.

System integration

Four systems, one shipment

Your terminal system, your ERP, your customs broker, and your customer's portal all hold a version of the same shipment. Making them agree usually means building connectors, mapping data models, handling failures gracefully, and monitoring the whole thing so a silent failure gets noticed.

Interface types we work with and what each one is typically for.
Interface Typical use here
EDI Container events, booking confirmations, and customs messaging with partners who have used the same message shapes for years.
REST and SOAP Modern partner APIs and the older service endpoints that still carry the routing and tariff lookups.
Message queues Event streams around the terminal where a missed message must be retried, not lost, and the sequence matters.
File-based Scheduled exports from systems nobody is going to change, wrapped in validation so a broken file is caught before it reaches finance.

We also build the reconciliation reports that tell you when something did not arrive — in this sector you do not get to pick a single interface and refuse the rest.

Enterprise application modernisation

Parallel, one workflow at a time

The systems that run a company for fifteen years accumulate weight: customisations nobody remembers, reports that break if a field moves, one person who understands the batch schedule. Replacing them wholesale is a project that fails more often than it succeeds.

We favour incremental migration, running old and new in parallel and moving one workflow at a time. That keeps a rollback path open and lets the operation keep running. Documentation is produced during the work, not reconstructed afterwards, so the knowledge stays with your team whatever happens next.

Parallel run

Old and new handle the same workflow side by side until the numbers agree for two full cycles.

Documentation during

Written as we learn it, reviewed with your team, so a batch schedule stops depending on one person's memory.

Rollback kept open

Every migration step ends at a point you can retrace, and none of them require a weekend shutdown.

Cybersecurity and ERP extension

Controls built in, upgrades survived

Port and logistics operations touch customs data and commercially sensitive schedules, so the expectations come from customers as much as from regulators. We build controls into the systems we develop and review the ones you already run — access control, audit trails, encrypted transport, and incident response planning.

For organisations with an established security function, we work inside your existing policy framework. Where there is a gap we cannot fill, we will name it rather than paper over it, and point to the kind of specialist who can.

Many Belgian industrial and logistics companies run an ERP that covers finance well and operations badly. Ripping it out is rarely the answer. More often the ERP needs extensions, custom modules, or a clean integration layer so that operational reality and financial record stop diverging.

We work with the major platforms and their extension points, and we are careful about upgrade paths: anything custom you build today has to survive the next version. That constraint shapes the design from the start.

How the lines fit together

Start where the risk is largest

Clients rarely buy one line in isolation. A modernisation project usually pulls in integration and data work. A custom build often ends with a cloud migration once the old server's replacement is due. Cybersecurity runs across all of it.

We scope the first phase around whichever line carries the most risk, and let the others follow once that is understood. It keeps the initial commitment small and the direction honest.

Five steps of an engagement

  1. Look at what you run

    We map the systems, the interfaces, and the people who keep them running. This is the part most vendors skip.

  2. Name the risk first

    The first phase is scoped around whichever service line carries the most risk to the operation — not whichever is easiest to sell.

  3. Write the scope down

    A short written scope with the open decisions listed, so the first small step is a documented one.

  4. Ship on a rhythm

    Something you can open, click, and comment on every two weeks. No six-month reveal, no surprises at the end.

  5. Let the next line follow

    Integration, data, or cloud joins the work once the first phase has answered its own questions.

Read the engagement models

Where we push back

We are happy to say that a project should stop at the warehouse, that a legacy system has earned the right to stay, or that the gap you have shown us is not one we should fill. A short scope with an honest boundary serves you better than a longer one that quietly grows.