AeroPulse - Designing one trustworthy picture of equipment for a drone logistics operation spanning a warehouse, dozens of field sites, and two countries.
- Role
- Product Design (solo, end-to-end)
- Duration
- 1 month
- Tools
- Base44, Claude, Notion, Framer
The question was never "how much is there." It was "who is willing to act on that number without checking it themselves first." A count that nobody trusts gets re-verified by hand anyway, which means it was never actually solving anything. Every decision in AeroPulse comes back to that one distinction. This case study is the argument for it, not a list of screens that happen to agree with each other.
The thesis
Most logistics tools treat equipment tracking as a counting problem. I treated it as a trust problem.
An operation like this runs equipment-heavy field deployments across dozens of active US sites, coordinated with a logistics team a full timezone-and-a-half away in Israel. Before a shared system, that meant parallel spreadsheets: one for cables, one for batteries, a separate shipment log, none of them reconciled. Nobody could answer "is this actually a problem right now" without phoning three people first.
Distributed operations don't fail because equipment is missing. They fail because nobody can prove, fast enough, that it isn't.
Every request that gets approved without checking existing stock elsewhere is a purchase that didn't need to happen. That's the number a business actually cares about, even without a dashboard to prove it: fewer duplicate purchases, fewer stalled shipments discovered too late, less time spent reconciling spreadsheets that disagree with each other.
The real cost isn't visibility. It's duplication.
Every competitor I looked at solved the counting half. None of them solved the trust half: the part where a number is only useful if someone's willing to make a decision on it without re-verifying it themselves.
A counting system tells you a number. A trust system tells you whether to act on it.
Two people carry this problem, at two different scales.
Who has to trust the number
When an LDO files a shortage, the system checks existing availability across every other active project before the request goes anywhere near procurement, and surfaces a direct transfer option in the same form. The Logistics Manager doesn't have to trust that nothing got double-ordered. She can see it herself.
Checking availability before a request becomes a purchase.
Low stock on a cable gets a warning icon and a status tag in its row. A concentrated defect root cause gets a red banner across the top of the screen instead, sitting right above the chart that explains it. Recoverable gets a signal in its row. Urgent and unexplained gets escalated straight to the evidence.
Matching the alert to how urgent it actually is.
Two places in AeroPulse ask a person to confirm what actually happened instead of letting a status update on its own. HQ-sourced components move through their pipeline with a manual Advance action. A shipment doesn't get marked arrived just because its ETA passed either: someone attaches the delivery photo and the bill of lading, and confirms it themselves. Nobody assumes something happened just because a field says so.
Confirming with evidence, not assuming from a status.
Two things are deliberately unfinished, each for a different reason.
What's next
Two things worth building, and one thing worth testing before building anything else.
The sidebar doesn't yet distinguish a Logistics Manager's full view from an LDO's, even though the reasoning is clear: this system is a side tool for an LDO and the whole job for a Logistics Manager. A real IA change, not built yet because none of the three decisions above depended on it.
LDO-scoped navigation
A transfer approved against a stale "available" count could leave the other project short, exactly the failure mode the whole thesis is supposed to prevent. Needs a "last
