Most shops I've worked in were not short on information. The information was in a filing cabinet, a fuel vendor's monthly PDF, a supervisor's truck, and four people's memory. Nobody could put it in the same place at the same time, so decisions got made on whichever piece was closest to hand.
HU.b is built around one idea: a signal is only worth capturing if a decision depends on it. An operator reporting a noise, a meter reading off a fuel receipt, a line item on a vendor invoice — each one exists in the system because something downstream needs it, whether that's a PM coming due, a repair getting scheduled, or a cost landing against the right truck.
What follows is that chain in four parts: how data gets in and gets trusted, how it turns into a prioritized decision, how the work gets executed, and how the money gets accounted for. The capability lists are long because the shop's real work is long. The reasoning under each one is the part I'd rather be judged on.
Five stages. Each one hands the next a more decided version of the same fact.
The reason this is worth drawing as a chain is that the last stage is where the value shows up and the first stage is where it's decided. Cost per asset is only trustworthy if the meter reading three steps earlier was validated, which is why most of the engineering effort went into the boring end.
Read the four summaries for the argument. Open a pillar when you want the implementation detail behind it.
Every touchpoint becomes a data point
You can't optimize what you can't see. I designed and built systems that capture fleet signals from every source — operator reports, meter readings, fuel card transactions, vendor invoices, daily inspections, recall notices, and vendor call notes — and normalize them into a single, queryable data layer. The product challenge wasn't just building inputs; it was designing validation, deduplication, and anomaly detection so that downstream decisions are based on trusted data.
Turning raw data into prioritized action
Data without decision frameworks is just noise. I built the intelligence layer that sits between raw equipment signals and operational execution: translating inputs into prioritized maintenance actions, escalation triggers, and proactive interventions. The product design challenge here is routing the right information to the right person at the right time — across 6 role tiers with fundamentally different needs.
Maximizing availability, minimizing downtime cost
Every hour a piece of equipment is down costs money: lost revenue, idle crews, missed deadlines. I built systems that minimize time-to-repair, eliminate duplicate work, and ensure nothing falls through the cracks between 'reported' and 'resolved.' The product insight: uptime optimization isn't one feature — it's a pipeline of handoffs between operators, technicians, vendors, and managers that needs to be instrumented end-to-end.
From repair costs to fleet-level P&L insight
Operations generates the data. Finance needs the story. I built the bridge: a financial container system that traces every dollar from vendor invoice to equipment cost center, with multi-tier approval workflows that enforce accountability before spend happens. The product design challenge was building completion gates strict enough to prevent gaps without creating friction that users would work around.
Counted from the live application. Nothing here is planned work.
I'd rather these numbers be read as scope than as achievement. What they describe is a system that has to stay correct while six kinds of user touch it every day, which is a different problem from building any one of these features once. The part I learned from was not the building — it was finding out which parts the shop actually used after I shipped them.