Skip to content
steelabs

Industries

Software quality in Logistics

A logistics platform is mostly other people’s systems. The code you own is the smaller risk; the surface that breaks is the set of partner APIs, sandboxes and batch feeds that change without asking and fail without saying so.

What shapes Logistics software

What tends to go wrong

  • Most of the surface is other people’s APIs, which change on their schedule and are rarely versioned as carefully as your own.

  • A shipment’s state is assembled from several systems, so a status can be wrong without any individual system reporting an error.

  • Partner sandboxes behave differently from partner production, which means integration bugs surface after go-live rather than before.

  • Volume is uneven and batch processes fail on the shape of the data, not the amount of it — one malformed record stalls a whole run.

What binds you

  • NIS2

    Transport is an Annex I sector, so operators above the size threshold are essential entities — risk-management measures, supply-chain security obligations that reach your integration partners, and incident notification on a defined clock. Transposition timing differs by member state, so the date that binds you is the one where your entity is established.

  • GDPR

    Consignee names, addresses, signatures and increasingly location traces are all personal data, and they flow through every partner you integrate with. Each of those integrations is a transfer that needs a basis and a contract, which is a data-protection question that gets settled in an API design review.

  • Cyber Resilience Act

    Relevant if you ship hardware — telematics units, scanners, tracking devices count as products with digital elements. Reporting duties for actively exploited vulnerabilities begin on 11 September 2026, with full application on 11 December 2027.

Engineering practice, not legal advice.

How we work on it

What that means in practice

We test at the integration boundary: contract tests against partner APIs so a change on their side fails your pipeline instead of your operations, and end-to-end automation that follows an order through ordering, tracking and status updates as one flow rather than as four isolated screens. Where sandboxes are unreliable, we build the fixtures that let the tests run anyway.

FAQ

Logistics questions we hear often

How do you test against APIs we do not control?

With contract tests that assert the shape and semantics you depend on, run on your schedule rather than theirs. When a partner changes a field, your pipeline goes red before your operations team finds out from a customer. It does not stop the change, but it moves the discovery from the warehouse to the build.

Our partner sandboxes are unreliable. Does that block automation?

No, it changes where the boundary sits. Tests run against recorded fixtures that encode the contract, so the suite stays green and fast regardless of sandbox availability, and a separate, smaller set of live checks confirms the real endpoint still matches the fixture. Coupling every test to a third party’s uptime is how suites become distrusted.

A shipment status was wrong but no system reported an error. How is that tested?

End to end, as one flow rather than four screens. State assembled from several systems can be individually correct at every hop and wrong in aggregate, so the assertion has to be on the composed result — follow an order through ordering, dispatch, tracking and delivery and check what the customer would actually see.

What about batch processes that fail on data shape?

They get negative and malformed-record cases as first-class tests, not as an afterthought. A run that stalls on one bad row is a data-shape failure, and the fix is usually about isolation and reporting rather than about the parsing itself — which is a design question a test makes visible early.

Contact

Building for logistics?

Tell us what you are shipping and where it worries you. You will get a considered reply from an engineer, not an autoresponder.