Case study
What was at stake
Bold sells payment terminals. That means the company does not only move money. It moves physical objects: card readers, cards and point-of-purchase material, from a warehouse into a merchant’s hands.
The logistics domain covers two worlds.
Inventory is about making the numbers reconcile and keeping traceability over every terminal, card and piece of POP material. It also covers the guardrails on how inventory is allowed to move, the integrations with systems that touch it, and the reporting on top.
Distribution is about getting the product to the customer. We integrate with third-party logistics providers, and here too we have to guarantee traceability and reporting across the whole process.
I work across both, and I own the subdomain that cuts through them: logistics issues.
The constraint
The happy path is the easy half. What makes this domain hard is that the plan regularly stops being true, and the system has to keep working anyway.
A concrete case. A shipping order is being loaded with a logistics provider, and it turns out that provider does not have availability for the full set of inventory to be dispatched. The shipment cannot go as planned.
Something has to decide what happens next. Route it through a different provider, split it, hold it. That decision cannot live in an operator’s head or a chat thread. It has to be a resolution strategy implemented in code, with the normal case, the edge cases and the ugly in-between cases all accounted for.
The other constraint is human. Logistics analysts are the people who have to understand what the system just decided, while it is still actionable. A resolution that is correct but invisible is not much use to them.
What I built
Resolution strategies. Each class of incident gets an explicit, coded path to resolution instead of an ad-hoc intervention. Most of the work is in enumerating reality honestly: what actually goes wrong, how often, what the legitimate responses are, and which of them can be taken automatically versus which need a person.
That list does not come from the codebase. It comes from the logistics analysts who have been absorbing these incidents by hand. So the first part of the job is sitting with them, watching what they actually do when a dispatch fails, and separating the steps that are genuine judgement from the ones they perform only because nothing else will. Only the second kind should become code.
Real-time visibility. Slack notifications surface incidents and their resolution to the analysts as they happen, so the team has a live view of the process instead of finding out from a report the next day.
Reporting. Metabase over dbt-modelled data, covering both inventory and distribution. The same traceability requirement that applies to a terminal sitting in a warehouse applies to an exception in a shipment.
One inventory view instead of several
Historical MPOS inventory data existed, but not in a shape anyone could ask business questions of. I migrated it into a dbt gold dimension, consolidating 446K+ terminals and 1.2M+ stock movements into a single view the business can actually read. Built with dbt, AWS Glue and Athena.
This is the unglamorous half of traceability. Knowing where a terminal is only counts if someone outside the engineering team can find out without asking.
Getting product out the door
Exceptions are one end of the problem. The other is the ordinary path working well. I built the inbound delivery workflows that let commercial executives deliver customer orders and link debit cards to payment terminals, which shortens the gap between a merchant signing up and a merchant actually transacting.
I also built CRM features for inventory confirmation and stock transfers between executives and warehouses, so movements that used to happen informally are recorded and controllable.
The part customers see
Most of this work is internal, but the logistics-provider integrations surface directly in the Bold app. A merchant can follow their order status and delivery events themselves rather than asking support where their terminal is. It is the one place where the logistics domain stops being back-office and becomes part of the product.
All of it in Python on AWS.
What came of it
Logistics issues stopped being interruptions handled by whoever noticed first. They are now a modelled part of the domain, with defined strategies, visibility while they are still actionable, and a trail afterwards.
The general lesson is one I keep relearning. In any system that touches the physical world, the exception path is the product. The happy path is a small, well-behaved subset of what actually happens, and how gracefully you handle the rest is most of what people experience.