DeliveryProof

Inspiration

In logistics, legitimate detention (wait-time) earnings are frequently lost or disputed. Evidence of arrival, check-in, and departure at facilities is often manual, fragmented, or missing entirely. GPS and ELD data prove a truck was near a facility — not that a driver actually checked in. Traditional ePOD systems only capture the final signature, not the chronological story leading up to it. Disputes rarely come down to whether goods were delivered — they come down to when things happened, and nobody has a shared, trustworthy record of that timeline.

What it does

DeliveryProof is an evidence-first accountability layer connecting Companies, Drivers, and a Reviewer in one workflow.

• A Company creates a trip as the Sender and selects a different company as the Receiver. The trip only publishes once the Receiver accepts.
• A Driver claims a published trip atomically (only one driver can ever hold it), executes the delivery, and uploads photo evidence at each stage — arrival, check-in, departure.
• A Reviewer independently verifies the identity of every Company and Driver from submitted documents (like a driving licence or GST certificate) before they get platform access — completely isolated from trip data.
• Once a trip completes, AI generates a natural-language summary of the full recorded timeline — condensing raw timestamps and photos into something a human can read in seconds.

The result: one shared, verifiable timeline nobody can dispute after the fact.

How we built it

Built on Next.js (App Router) with a Supabase (PostgreSQL) backend and Supabase Auth for role-based identity. Delivery evidence and lifecycle transitions are handled with strict server-side authorization — an atomic claim mechanism ensures a trip can only be claimed by one driver, and a receiver-agreement gate prevents a trip from publishing until the receiving company explicitly accepts. AI (via Groq) is layered strictly on top of this deterministic core — it only runs after a trip completes, summarizing evidence that already exists, never making operational decisions.

Challenges we ran into

Keeping the three roles cleanly separated was the hardest part — making sure a Reviewer genuinely has zero visibility into trip/delivery data, while still being able to verify identity effectively. Building the sender ≠ receiver integrity rule and the atomic claim system (avoiding race conditions when multiple drivers try to claim the same trip) required careful server-side logic rather than relying on the client. Keeping AI strictly a summarizer — and never letting it influence deterministic operational rules — was a deliberate design boundary we held throughout.

What we learned

Clear role boundaries matter more than feature count. A lot of the platform's trustworthiness comes from what each role can't see or do, not just what it can. We also learned to treat AI as a narrow, well-scoped layer — bolting AI onto every decision would have undermined the deterministic guarantees that make the evidence trail trustworthy in the first place.

What's next for DeliveryProof

• Offline mode for drivers to queue evidence and sync on reconnect
• A full RLS (Row-Level Security) rewrite to close a known reviewer service-role gap
• Richer AI evidence summaries with more supporting detail
• Public shareable evidence links for external stakeholders (e.g. insurers, clients)

Built With

• groq
• next.js
• postgresql
• react
• supabase
• tailwind-css
• typescript
• vercel