How I'd build Pylon
I'd reach for Next.js on the frontend for the dispatch board itself, FastAPI on the backend to handle real-time grid updates and the driver assignment algorithm, Postgres for spatial queries on driver locations, and Stripe for billing. For notifications I'd use Twilio for SMS and Resend for email. I'm estimating 350 hours solo, with the understanding that integrating live GPS feeds from ELD vendors eats a significant chunk of that upfront. That's roughly 9 weeks at 40 hours a week, but we can ship value incrementally and let the GTM team start demoing around week 4.
Day-by-day plan
- Day 1-2: Provision multi-tenant Postgres schema with tenant isolation at the row level, user auth via NextAuth, and role-based access for dispatchers vs. driver app users.
- Day 3-4: Build the core dispatch board UI in Next.js - drag-and-drop load cards, driver status sidebar, live ETA tracking on a map. No real-time sync yet, just polling.
- Day 5-7: Implement the driver-matching algorithm in FastAPI. Takes a load (origin, destination, weight, pickup window) and rank-scores available drivers by HOS compliance, CDL class match, and dead-head cost.
- Day 8-9: Stripe integration for three pricing tiers and per-load metering. Handle invoice drafts as POD confirmations come in.
- Day 10-11: Plug in the first ELD provider SDK (start with Samsara since they have the highest market share in this segment). Fetch driver locations every 30 seconds and sync back to the board.
- Day 12-14: Notification layer - Twilio SMS for dispatch alerts, in-app push for driver-side confirmations, email digests for the dispatcher.
- Day 15-16: Spike on HOS compliance validation. Build the rules engine that enforces the 11-hour driving limit, 14-hour on-duty window, and tracks split-sleeper hours for team drivers.
- Day 17-18: POD capture - image upload on the driver mobile app side, signature parsing if we have time, and the automatic invoice-draft generation.
- Day 19-20: Testing, load tests, and basic ops runbook. Deploy on Railway or Render. Buy the domain, wire up CDN.
What's hard about this build
The core tension is that the dispatch board itself is straightforward CRUD with a nice UX, but the value is entirely in the ELD integration. Different vendors structure their APIs differently, and GPS data latency matters - a five-minute staleness will break the real-time experience and you'll get feature requests immediately. The bigger risk is that once a fleet uses Pylon for a month and then upgrades to a Samsara or Motive subscription, they'll see dispatch bundled in at effectively zero marginal cost. You're fighting against a vendor-lock pattern. On the technical side, the HOS rules engine is correctness-critical - get it wrong and the dispatcher dispatches an illegally fatigued driver and you're liable. I'd plan for audit-trail logging and requiring manual override with acknowledgment before violating a rule.
What's fast because of AI
Scaffolding the Next.js dashboard and FastAPI backend goes from a week to a day using Claude with context awareness of the schema. Test writing for the driver-matching algorithm accelerates significantly because I can enumerate edge cases (team drivers with split sleeper, hazmat plus tanker endorsement conflicts, HOS restart windows) and Claude generates the test suite faster than I'd write it myself. Copywriting for the dispatch UI - microcopy for alerts, modal text, notification formats - would normally take iteration with the GTM team. Instead, I draft it in the product and Claude refines it based on the trucking vocabulary from the spec. Debugging is where the real win is: when the ELD polling breaks or the Stripe webhook silently fails, Claude helps trace through logs and surface the root cause faster than manual inspection.
How I'd hand it off
I'd record a Loom walkthrough of the dispatch board, the driver app, and the Stripe admin setup. Leave a 30-day ops runbook in the repo covering deployment, common errors, ELD credential rotation, and Stripe sync logic. Set up a 30-day pager rotation where I'm on call for the first two weeks, then hand to your ops person. Transfer Stripe API keys, ELD SDK credentials, and Twilio account ownership. The codebase is yours to modify or extend - I'd leave clear architecture notes on the driver-matching algorithm so your next hire can tune it.