From Dispatch Chaos to Production

When I began developing Vigil in January 2026, I wasn’t starting with a product specification. I was starting with an operational problem.

An Atlanta-based freight carrier coordinated loads, drivers, status updates, and shipping documents through calls, texts, and manual processes. The work got done, but information was fragmented. Dispatchers chased updates, documents lived in different places, and reconstructing a load’s history required piecing together multiple conversations.

My objective was not simply to digitize dispatch. It was to create a dependable workflow from assignment through delivery and document closeout.

About eight weeks after discovery began, Vigil reached initial production use. Four decisions shaped that outcome.

1. Map the work before deciding what to build

I mapped the complete load lifecycle: job creation, assignment, pre-trip checks, pickup, transit, delivery, documentation, and closeout.

That exposed problems invisible when each task was considered separately. A dispatcher might know a delivery was complete without having its supporting proof. A driver could report a status by phone without creating an enduring operational record. An invoice might depend on documents still scattered across devices.

I treated these as connected process failures rather than independent feature requests.

The resulting product centered on a shared job record, with administrator, dispatcher, and driver roles responsible for different parts of the same workflow. This created a common source of operational context instead of another interface layered over fragmented processes.

Decision: Design the operating model first, then make the technology support it.

2. Build in dependency order, not feature order

The next challenge was sequencing. Many capabilities looked valuable; fewer were necessary to get the first carrier operating reliably.

Driver assignment depended on onboarding and role permissions. Document generation depended on accurate job data and pickup or delivery evidence. Customer visibility depended on trustworthy status updates.

I prioritized the chain that made a load executable from assignment through closeout. Production readiness meant testing that chain end to end, including permissions, driver workflows, and documents.

I also made a deliberate trade-off on location tracking. Continuous background tracking needed device-level validation and operational safeguards. Rather than hold the core release hostage to that dependency, I kept driver-reported updates available and treated advanced tracking as a separate release concern.

Decision: Defer features whose prerequisites were unproven without compromising the essential workflow.

The practical lesson was that speed came from reducing dependency risk, not trying to ship everything at once.

3. Use AI to accelerate intake, not replace accountability

As Vigil evolved after the initial release, I added Claude-powered voice and SMS intake. Incoming freight inquiries could become structured opportunities for dispatcher review.

I did not allow the AI to accept loads autonomously.

Understanding an inquiry and committing a carrier are different problems. Acceptance depends on fleet capacity, timing, commercial terms, and operational judgment. Dispatchers retain authority to review, accept, or reject an opportunity before Vigil creates the job.

This became a broader design principle: automation should reduce coordination work while making decision ownership clearer, not less visible.

4. Treat production feedback as evidence

Real use challenged assumptions that planning had missed.

Drivers sometimes needed to manage concurrent jobs, which meant assignment order, selected-job state, and document association had to remain correct across overlapping work. Users also exposed problems with navigation cues, low-contrast controls, mobile layouts, and onboarding flows.

These were not merely cosmetic defects. A driver who cannot identify the right control, or complete onboarding, cannot reliably participate in the process.

I used carrier feedback to revise requirements and validate fixes against actual workflows. The quality standard shifted from “does this feature function?” to “can someone use it correctly while doing the job?”

5. What I would do differently next time

I would change three things in a second implementation.

Test on real devices sooner.

Device differences and navigation patterns should be part of acceptance testing before rollout, especially for drivers.

Measure operational improvement from day one.

Vigil has since processed more than 1,000 loads and provisioned 25 users, but those figures show usage and reach, not hours saved. I would capture baseline status-call volume, document turnaround, and onboarding friction so the operational impact could be measured directly.

Standardize carrier activation earlier.

Contract execution, payment confirmation, account configuration, permissions, and readiness testing should follow a repeatable process rather than depend on ad hoc founder coordination.

What the experience proved

Vigil moved from an ambiguous carrier problem to production use by a paying Atlanta freight carrier across administrator, dispatcher, and driver roles. The first eight weeks established the core workflow; continued development and customer feedback expanded it afterward.

I learned that building an operating system is less about accumulating features than about understanding how work moves, deciding what must happen first, and ensuring the system holds up when real operations challenge the plan.

Gabriel Odeyemi is the founder of Vigil, a freight operations platform developed through DGO Ventures.