What should a freight team do first?

PortSight is a financial-exposure tool for freight operations: for the people who learn on a Tuesday that a customs filing was missed, a port is closed, and a carbon declaration is short by 170 tonnes, each with its own deadline and price.

I built it alone, from design through front-end. The first version did what most tools in this category do: it monitored beautifully. Risk index, active disruptions, regulatory intelligence, a map. You could study it for a minute and still not know what to do next.

The work came down to four decisions, one for each surface: show the situation, or hand someone the next move. I made them separately, then realised they were the same decision four times.

A shipment is late, a filing is overdue, a port is closed. The systems that track this are good at surfacing all of it and they leave the hardest part on the desk: of the nine things currently wrong, which one costs the most if you deal with it after lunch?

That’s not a data problem. Everything needed to answer it is already on the screen: the deadline, the fine, the route, the owner. It’s an arrangement problem, and arrangement is the part nobody treats as a decision.

Four surfaces, and for each one an A and a B taken to working prototype rather than to a comparison table. Then a decision, written down with the rejected option and the reason next to it, so a call made in April can still be argued with in June.

What follows is that log. Three of the four rejections are things I had already built and liked.

The map is the screenshot you put in a portfolio. It is the thing that makes a logistics prototype look like a logistics product, and it took real work to build.

It also answered a question nobody in this workflow asks. An operations manager does not need to know that a vessel is somewhere in the Indian Ocean; they need to know that the import security filing on it expires in six hours. The dots were decoration dressed as instrumentation, and every minute a user spent looking at them was a minute not spent on the thing with a countdown attached.

That sentence is in the decisions log, and it is written after the four entries above it rather than before them. I did not start with a thesis and apply it four times. I made four separate calls about four unrelated screens, wrote down why each one went the way it did, and then read the log back and found I had been answering the same question all along.

Which is an argument for keeping the log. The pattern was not visible from inside any single decision.

The rejected directions aren’t wrong. A cockpit, a real map, a wizard, an analytics grid, each is the right next layer once the decision layer underneath is proven, and each needs data fidelity this prototype doesn’t have. Build the decision layer first, then add awareness on top of it. That ordering is the product plan.

No engineer on this, so the design system is a real one rather than a Figma library. Shared style values in code, seven shared components, three severity tiers, motion timings with entrance and exit easing separated. The discipline matters on a solo project because the design decisions have to survive me implementing them at eleven at night.

The system doc carries a Known Drift section listing what’s still wrong: off-grid spacing at 7px, 10px, and 14px, and page-level styles still using hardcoded font sizes where the shared components read from the shared values. Writing the backlog down is what stops the drift being rediscovered later as a surprise.