Custom business system

Cross-border order management system

One order lifecycle from customer request through international purchasing to shipping and local delivery — replacing a process that lived in chat threads and spreadsheets.

[ Custom business system — screenshot ]

An order management system for a cross-border trading operation. A customer requests an item; the business sources and purchases it internationally; it is consolidated, shipped, cleared, and delivered locally. The system digitizes that whole chain as one order lifecycle.

Delivered for a client in cross-border commerce. Named details, figures, and outcomes are omitted — no permission to publish them has been given. What follows is the engineering, which is mine to describe.

The problem it solves

Cross-border ordering is unusual because a single customer order becomes several different things on its way through the business. It starts as a request, becomes a quote, becomes an international purchase from a supplier, becomes cargo in a shipment with other people’s orders, becomes a customs entry, and finally becomes a local delivery.

Run without a system, each of those stages lives somewhere different — a chat thread, a supplier’s email confirmation, a spreadsheet of shipment contents, a courier’s tracking page. The customer asks “where is my order,” and answering it means a person reconstructing the story from four places. Nobody can see the true landed cost of an order until well after it has been delivered.

What makes it hard

  • The order is not one object. A customer order and a purchase order are different things with different lifecycles, and the mapping between them is many-to-many: one customer request can require several suppliers, and one supplier purchase can serve several customers. Modelling this as a single “order” record is the mistake that makes everything afterwards painful.
  • Consolidation breaks the one-to-one assumption again. Items from many purchases travel in one shipment. Shipment status is therefore a property of the shipment, not of any order — but the customer only cares about their own items, so the system has to project shipment events down onto individual orders correctly.
  • Landed cost is calculated, not entered. Item price, international shipping, customs and duties, local delivery, and currency movement between order and payment all contribute. Allocating a shipment’s shared costs fairly across the orders inside it is a genuine business rule that has to be agreed, not assumed.
  • Currency changes meaning at every stage. Quoted in one currency, purchased in another, settled in a third. Which rate applies at which moment is a decision with accounting consequences.
  • Customers want visibility into a process that is genuinely uncertain. Honest status communication — without promising dates the business does not control — is a product design problem as much as an engineering one.

How I approached it

  • The order lifecycle first, defined with the business before any screen existed: every state, every transition, and who or what triggers it. Separating customer order from purchase order from shipment at the model level was the decision the rest of the system rested on.
  • Status as derived, not typed in. Order status is computed from the events that actually happened — purchase confirmed, shipment departed, cleared, out for delivery — rather than a field someone remembers to update. If status is manual, it is wrong.
  • Automate the reconciliation, not the judgement. The system removes the copying and the arithmetic. Decisions that need a person — which supplier, whether to hold a shipment — stay with the person, surfaced with the information needed to make them.
  • Operations tooling as a feature. Someone will need to split an order, reassign an item to another shipment, or correct a cost allocation on day one. If that only exists in the database, the business pays for it every week.

Where this is relevant to you

If your process spans several parties and several stages and currently lives in chat threads and spreadsheets, this is the same class of problem. The value is rarely in one clever feature — it is in modelling the lifecycle honestly, deriving status from events, and building the tools your operations people need to intervene when reality departs from the happy path.

Working on something like this?

Start a conversation

← All case studies