Expeditoo: a logistics marketplace with bidding and tracking in one system

A logistics marketplace carries two-sided complexity: a bidding layer where price is discovered, and an operational layer where shipments are tracked to completion. Built separately, the two drift apart — the marketplace promises what operations cannot reliably deliver, and the data never lines up.

For Expeditoo the challenge was unifying these into a single application with consistent business logic across both.

The approach was to treat bidding and tracking as one domain with one source of truth, not two integrations. That means defining the shared data model first, then building the bidding and tracking flows on top of it so they stay consistent by construction.

The result was delivered as a production system the client owns — full-stack, handling the complex business logic a two-sided logistics platform requires.

Instead of two systems to reconcile, Expeditoo runs one application where a bid and the shipment it produces share the same record. The public project summary describes it as demonstrating full-stack capability across complex business logic.

Operational metrics are being prepared for publication and will appear here and on the transparency page.

For two-sided platforms the lesson is structural: model the shared domain before building either side. Most marketplace pain comes from a bidding system and an operations system that were built separately and never agreed on the data. One source of truth removes a whole category of later problems.

If your platform's two sides argue about what happened, the fix is usually upstream in the data model, not in either feature.

A logistics marketplace is two businesses wearing one logo. The bidding side behaves like a financial exchange — prices move, offers expire, counterparties commit — while the tracking side behaves like an operations desk, where a shipment is a physical thing moving through real-world states. Most teams staff and build these halves separately because they feel like separate disciplines, and that organisational split quietly becomes an architectural one. The bidding system learns to think in offers and money; the operations system learns to think in legs and milestones; and nothing in the codebase forces them to agree on what a single job actually is.

The split is rarely a one-off mistake — it is the path of least resistance for a growing platform. A marketplace usually launches with the bidding flow because that is where the demand-side excitement lives, then bolts tracking on once the first shipments need to move. By the time tracking matters, the bidding side has already defined its own vocabulary, and integration becomes a translation problem between two models that were never meant to be one. This is why the pattern recurs across logistics, freight, and procurement platforms regardless of size: the order in which features get built almost guarantees the data drifts.

The honest framing is that this is not a technology gap. The teams who hit it are competent; the failure is structural, baked in before anyone wrote a line of integration code. That is also why it is fixable — a structural problem responds to a structural decision, made once, about where the truth lives.

The core decision on Expeditoo was to make a single record the spine of the whole platform — the job — and to treat bidding and tracking as two views of that one record rather than two systems exchanging messages about it. When a bid wins, it does not 'create' a shipment in a separate operations database; it transitions the same job into its operational phase. Price, counterparty, route, and status are attributes of one thing with one identity, so there is no synchronisation step that can fail, lag, or disagree.

This sounds obvious stated plainly, and that is the point — the difficulty is not the idea but the discipline to define the shared domain before either flow is built. The domain model has to anticipate the full lifecycle of a job from open auction through to delivered shipment, including the awkward states in between: a bid accepted but not yet collected, a shipment in transit whose terms are being renegotiated, a job cancelled after award. Getting these states named and owned by one model up front is what lets the two flows stay consistent by construction rather than by reconciliation.

The payoff is that an entire class of bug simply cannot occur. There is no 'the marketplace says delivered but operations says in transit' incident, because both sentences are reading the same field. Consistency stops being a feature the team maintains and becomes a property of the schema — which is exactly the kind of variance the methodology exists to remove before a fixed price is quoted.

A two-sided marketplace invites scope in every direction — dynamic pricing engines, carrier rating algorithms, automated route optimisation, in-app messaging, analytics suites. The discipline of an eight-week clock is choosing not to build most of it. The decision rule is the same one applied across every engagement: build the one structural thing that everything else depends on, and refuse the features that can be added later without re-architecting. The shared job model is that structural thing; a recommendation engine is not.

Several tempting additions were left out on purpose because they belong on top of a stable domain, not inside the foundational build. Sophisticated pricing intelligence, predictive ETAs, and counterparty scoring are all genuinely useful — and all of them are cleaner to build once a single source of truth exists to train and measure them against. Building them first, on an unstable model, is how platforms end up with clever features sitting on data they cannot trust.

Naming this plainly is part of honest delivery: a marketplace that works is not a marketplace with every feature. The first build's job is to make the platform coherent and ownable, so the operator can decide — with real telemetry, on their own infrastructure — which of the deferred features actually earn their place.

The clearest symptom is an argument about facts. If the people running your demand side and the people running your fulfilment side regularly disagree about the status of the same job — and resolve it by checking two screens and picking one — the platform has two sources of truth and the disagreement is structural, not human. A second tell is the integration job that never quite finishes: a sync process, a nightly reconciliation, or a queue of mismatches someone clears manually. That maintenance tax is the recurring cost of a model that was split too early.

A more subtle indicator is feature paralysis. When straightforward additions — a status notification, a simple report, a fee adjustment — require touching two systems and reconciling their assumptions, the data model is telling you it was never unified. Operators often misread this as the codebase being 'complex'; more often it is two coherent codebases that disagree at the seam. The cost shows up as slow delivery rather than visible outages, which is why it goes unnamed for so long.

If these symptoms are familiar, the bottleneck is almost certainly upstream in the domain model, and the highest-leverage move is to map it before building anything new on top. That mapping is precisely what a two-week Diagnostic is for — confirming whether the seam is the real constraint before a single feature is quoted.