Vantar: a full-stack field operations PWA for a veteran-owned m…

A mobile-first Progressive Web App for a veteran-owned medical courier company managing federal and commercial logistics contracts: real-time dispatch, chain-of-custody proof, financial analytics, and an AI assistant built into the workflow. Designed, built, and shipped solo; in active production use.

Solo: product scope, database, UI, AI integration, deployment

May 2026–present, ongoing maintenance

React, Vite, Supabase, Claude API, Vercel

Owner Dashboard: business metrics at a glance. Seed/demo account, no real client, contract, or driver data shown.

The client, 29 Integrity Logistics, LLC, is a 100% service-disabled veteran who owns a small SDVOSB (Service-Disabled Veteran-Owned Small Business) medical courier company, specimen and supply deliveries, split between federal contracts sourced through SAM.gov (the federal contracting portal; VA, DoD, HHS) and commercial/broker-booked hauls. Before this product existed, the business ran on paper logs, text messages, and spreadsheets, which created three concrete gaps:

Medical specimen transport carries real compliance stakes, and there was no timestamped, geotagged record tying a photo or signature to a specific delivery.

A dispatcher assigning a run and a driver executing it had no shared, real-time view of status.

SAM.gov registration lapses, contract renewals, and margin per run were things the owner found out about late, not early.

The brief, in effect: build the tool a two-person office-and-fleet operation actually needs, not a scaled-down version of enterprise transportation-management software they'd never fully use.

Three roles, three genuinely different jobs, one shared data model. Rather than one dashboard with permission-gated widgets, each role gets a different home screen built around its actual task: a dispatcher opens the app to decide something, a driver opens it to do something.

Desk, intermittently on the road. Needs business health at a glance: revenue, compliance deadlines, fleet status, contract pipeline.

Desk. Needs to assign runs, track them in real time, and manage fleet and crew.

One-handed, in a vehicle, often with poor signal. Needs today's run, fast proof-of-delivery capture, and to get paid correctly.

The owner's Dashboard leads with business metrics and compliance alerts; the driver's is a "Today / Upcoming" run list with nothing else competing for attention. That split came directly from watching how differently the two roles actually open the app.

When the live SAM.gov call fails (which, for a public government API, it sometimes does), the UI doesn't hide it behind a blank "no results" screen or invent listings to fill the space. It states the actual failure reason where the results would go, and computes any relative deadlines off today's date instead of shipping dates that quietly go stale. No results means no results, not fabricated ones.

A driver on a weak cell connection who sees "Uploading…" with no feedback and no retry doesn't have a technical problem, they have a lost proof-of-delivery problem. Every upload has an explicit timeout so a stalled request fails visibly and retryably, and photos are compressed client-side before upload since phone-camera JPEGs routinely run 3–12MB.

Built around a shared Postgres schema with role-scoped access enforced at the database layer (Supabase Row Level Security), not just hidden in the UI. Six surfaces below cover the core workflow; plus fleet/driver records with compliance-doc expiry alerts, an offline queue for low-signal areas, in-app team messaging, and IFTA (International Fuel Tax Agreement) mileage reporting, live but not detailed individually here.

Runs move through a fixed status pipeline with real-time updates (Supabase Realtime), split by contract vs. commercial and by loaded vs. deadhead miles.

Camera capture with GPS tagging, touch signature capture, and an event log written on every status change: the compliance-critical flow the whole product exists to fix.

Live SAM.gov opportunity search, AI-scored against the company's NAICS (federal industry-classification) codes and SDVOSB status, with an explicit failure state, not invented listings, if the government API is down.

Revenue vs. expense trends, cost-per-mile, and expense breakdown by category, plus an auto-generated invoice from any completed run.

A Supabase Edge Function proxies the Claude API for an in-app assistant scoped to the company's own live data, and flags runs running >40% over average duration.

Pre-trip and post-trip checklists (tires, brakes, lights, cargo, temp-sensitive storage) with Pass/Fail/N/A per item; a failed item blocks submission until the driver adds a note.

Contracts: live SAM.gov opportunities, AI-scored against the company's NAICS codes. Seed/demo account, no real client or contract data shown.

Finances → Analytics: revenue/expense trend and cost breakdown, the source for the "Financial analytics" surface above. Seed/demo account, no real financial data shown.

Run detail: the chain-of-custody flow the product exists to fix, photo capture and a branded PDF, one tap away. Seed/demo account, no real run data shown.

The AI assistant, scoped to the company's own live data, answering a financial-summary question mid-workflow. Seed/demo account, no real financial data shown.

Vehicle inspection: a failed item blocks submission until the driver adds a note, not a silent checkbox.

IFTA Report: quarterly mileage by jurisdiction, exportable for filing. Seed/demo account, no real mileage data shown.

Most trucking/TMS (transportation-management software) tools ship the same generic feature set whether the cargo is freight or lab specimens. Three things here don't show up on a typical off-the-shelf feature list:

SAM.gov opportunities are pulled live and AI-scored against the company's actual NAICS codes and SDVOSB status: ranked matches with a one-click "save as contract," not a search box the owner has to babysit.

Not a chat widget bolted on. It answers "show me this month's expenses" by querying the real revenue/expense tables, scoped server-side to that company only, grounded in the current date so it doesn't reason from stale training-data time.

Photo, GPS, and signature on every status change, because "delivery proof" means something more specific for a company hauling lab specimens under federal contracts than for a general freight hauler.

That's not a claim this beats mature TMS platforms feature-for-feature. ELD/HOS (electronic logging device / hours-of-service) compliance and live fuel-card integration aren't built, and would likely mean integrating an existing certified provider rather than building from scratch. The case for this product is narrower: built deep around the real constraints of one business, instead of a broad tool the business configures around the parts that don't fit.

Lighthouse audit, production build:

A working owner, real compliance deadlines, and no budget for enterprise software set the actual constraints here, not a brief. Understanding the business meant sitting with how the owner and drivers actually worked, not just interviewing them: the paper logs, the texts, the spreadsheets they were replacing. From there it was scoping what a two-person office-and-fleet operation would actually use, then building it end to end, database schema, role-based UI, AI integration, and deployment, and keeping it running for a client who depends on it. That's the competency this project demonstrates: taking a real business problem through to a shipped, maintained tool, not a research exercise or a portfolio piece built without a client on the other end of it.