Context before conclusions
Review site delays, tracker health, and evidence before assigning responsibility.
FLEET MANAGER / FEWER CALLS. CLEARER DAYS.
Keep loads moving.
Stop chasing updates.
Connecting the work
behind every load.
One operating day.
One connected view.
Fleet Manager brings assignments, driver updates and delivery records together. Dispatch knows what needs attention, drivers know the next job, and the office spends less time piecing the day back together.
Request prototype access- WHAT I BUILT
- Product strategy, UX & full-stack delivery
- THE COLLABORATION
- Fleet-operations subject-matter expert
- THE SYSTEM
- Dispatch, driver experience & backend orchestration
01 / The context
The challenge was not tracking trucks. It was connecting the work.
Fleet operations bring dispatchers, drivers, job sites, and the office into a constant exchange of decisions. A location pin can show where a truck is. It cannot, on its own, explain what the truck is doing, what is holding it up, or whether the completed load is ready to reconcile.
Working with a fleet-operations subject-matter expert, I translated firsthand operating knowledge into business and technical requirements. Repeated coordination calls became a need for shared assignment status. Unclear site activity became a need for project-level context. Missing delivery records became a need for evidence tied directly to the load.
That translation shaped Fleet Manager: a connected operating platform built around the relationship between the people, the work, and the decisions that move a fleet forward. Every feature had to answer a real operating question, not simply add another screen.
02 / People and workflow
One operating picture. A clear next move for every role.
For dispatch, the question is what can move next. For a driver, it is where to go and what the job requires. For a manager, it is where the operation needs attention. For the office, it is whether the evidence supports closing the work.
I connected these perspectives through a shared load lifecycle. Assignments, progress, site activity, and proof of delivery stay attached to the same work, so a handoff between people does not become a break in the record.
The workflow accommodates internal drivers and outside haulers without erasing company affiliation or responsibility. Each person receives the context and actions relevant to their role; the operation retains a coherent view across the whole day.
03 / My contribution
From the expert's operating knowledge to the system behind the experience.
I owned the translation from domain expertise to product delivery: discovering the operating problem, defining business requirements, specifying system behavior, designing the experience, and implementing the frontend and backend orchestration that connects it.
I turned requirements into a connected domain model for companies, people, projects, sites, trucks, work orders, loads, and delivery evidence. That model informed both the interface and the supporting APIs, persistence, access rules, and workflow transitions. The screen and the system were designed around the same operating logic.
I built the orchestration around meaningful events: an assignment accepted, a load progressing, evidence submitted, or an exception raised. State validation, background processing, notifications, and an audit history carried each event through to the people and records it affected.
My role was not to hand off a polished interface and leave its behavior to interpretation. It was to connect product strategy, UX, technical requirements, and implementation into one accountable delivery.
- 1Create the work
- 2Assign the driver
- 3Follow the movement
- 4Capture the proof
- 5Review exceptions
05 / The design decisions
Every feature starts with an operating problem.
Dispatchers needed to see progress, not just location. I introduced a Kanban view of assignments and their trucks across the work lifecycle: queued, assigned, loading, in transit, at delivery, and ready for review. The board made bottlenecks and the next actionable assignment visible in one scan.
A visual status change needed operational meaning. I connected transitions to backend validation, role permissions, and an audit trail, with completion dependent on the required evidence. The board became a working control surface, not a second record someone had to update independently.
An idle signal needed context before judgment. Project boundaries, pickup and drop-off zones, tracker health, and supporting evidence helped reviewers distinguish site conditions from driver issues. Human review stayed part of the workflow.
Missing paperwork needed to be addressed while the job was still in motion. Proof requirements followed each load into the driver experience and returned to a review queue, linking field activity to the office's reconciliation work.
Two levels of geography
Adjust the project perimeter and pickup or drop-off boundaries independently.
Evidence in the workflow
Surface missing proof while the work can still be reconciled.
Continuity over more screens
Keep the project, driver, load, and next action connected.
06 / The experience
A decision in dispatch carries all the way through delivery.
A dispatcher moves from an operating overview into a project, then into the assignments moving through its Kanban stages. The board reveals flow; the map explains location and site context. Both lead back to the same truck, driver, and load.
The backend coordinates what follows: persist the assignment, verify the permitted state change, notify the driver, and keep the operating views aligned. Background work handles follow-up outside the immediate interaction, while event history makes it possible to understand how the record reached its current state.
The driver receives the destination, material, load details, and proof requirements in a focused mobile experience. Progress and submitted evidence return to the shared workflow, where exceptions can be reviewed without reconstructing the job from calls and messages.
The value is the continuity: what dispatch plans, what the driver does, and what the office reviews belong to one connected product.
FROM THE OFFICE TO THE CAB
The next job.
Without the next phone call.
Pickup. Drop-off. Material. Load. Proof. The driver sees what matters for the assignment, in the order it matters.
Accept the job, keep dispatch in reach, and carry the same operating context into the field.
See the workflow07 / What we learned
Measure the work removed, not the number of features added.
The product's value rests on fewer coordination loops, less time reconstructing a load, and more complete evidence at handoff. The interface makes those goals visible; the orchestration makes them consistent across roles and events.
An illustrative 50-truck operating model explores reducing administration from 12 to seven minutes per load. Across 4,400 monthly loads, that would free approximately 367 hours. A 95% first-pass proof-completeness target describes the desired reduction in reconciliation work. These are modeled outcomes, not measured customer results.
The broader design principle is traceability: every operating problem maps to a requirement, every requirement to a behavior, and every behavior to an outcome worth evaluating. That is how the product earns its complexity.
ILLUSTRATIVE OPERATING MODEL / NOT MEASURED RESULTS
42%
Less administration per load
12 minutes to 7 minutes
367 h
Monthly capacity recovered
Across 4,400 monthly loads
95%
First-pass proof completeness
A 15-point improvement
08 / What comes next
An operating foundation with room to become a business.
The platform's growth path builds on a repeatable operating model rather than a growing collection of custom screens. Company-specific configuration, role-based access, customer data boundaries, dependable onboarding, and observable workflows form the foundation for serving more fleets.
An illustrative commercial model considers five outside fleets with 250 paid trucks at $49 per truck per month: $12,250 in monthly recurring revenue before costs. This is a planning scenario, not existing adoption or booked revenue.
The next product decisions follow the operating evidence: where dispatch still encounters friction, which exceptions repeat, and what teams need to trust the system at greater scale. The aim is a platform that improves how a fleet works, not simply how its data looks.
ILLUSTRATIVE 24-MONTH EXPANSION MODEL$12,250 MRR
5 outside fleets · 50 paid trucks each · $49 per truck per month, before costs.
FROM OPERATING KNOWLEDGE TO PRODUCT VALUE
Working through
something similar?
I help operators turn complex workflows and firsthand expertise into focused, usable products.