MeatLogix

At a glance

The challenge

Cold-chain meat distribution looks easy on a slide and is brutal in reality. A typical day involves:

• Trucks losing signal in industrial zones and across long routes.
• Drops that consolidate (10 customer orders into one truck route) or split (one supplier delivery split across three warehouses).
• A workforce — drivers, dispatchers, ops managers, auditors, executives — who all need different views of the same shipment data.
• Cold-chain integrity that must be logged for compliance and dispute resolution.
• Existing tools built for one shipment topology (point-to-point) when reality is four (1:1, 1:N, N:1, N:N).

The brief: a dispatch platform that handles every topology, works when connectivity doesn't, and surfaces cold-chain risks before they cost money.

What we built

A multi-role React application with Supabase + Postgres backend. Built mobile-first because the drivers and warehouse workers use it more than the office team.

Topology support

The core insight: most dispatch platforms model shipments as a directed edge from one node to another. Reality is a hypergraph. A single shipment can have multiple sources, multiple destinations, partial fulfillment, and inter-warehouse transfers along the way.

We modeled this in Postgres with a clean schema: shipments, shipment_legs, shipment_items, with materialised views for the common query patterns (driver's route, dispatcher's day, audit trail). This lets us express:

• 1:1 — simple point-to-point.
• 1:N — one supplier to multiple destinations (a single truck dropping at multiple customers).
• N:1 — multiple suppliers consolidating at one destination (warehouse intake from several producers).
• N:N — full hypergraph with consolidation and split en route.

Every screen renders correctly regardless of topology.

Offline-first architecture

Drivers in the field cannot wait on a spinner when they're handing meat to a customer. We built the entire driver app to be offline-first:

• Local Postgres-compatible store (via Supabase + IndexedDB) holds the day's routes.
• All driver actions (delivery confirmation, signature, photo, anomaly flag) write to local first.
• A sync engine replays local writes to the server when connectivity returns.
• Conflict resolution on reconnect: server-side last-write-wins for ground truth fields, client-side preservation for driver-recorded fields like signatures and notes.

This means the truck keeps working through dead zones. The office sees the data when the truck comes back online.

Five role-aware dashboards

Each role sees the same underlying shipment data filtered and shaped for their workflow. No role sees data they don't need.

Cold-chain integrity logging

Every shipment has a temperature log: source, route, destination. Anomalies (temperature excursions, late deliveries, missing photos) get surfaced on the dispatcher cockpit before they cost the business in customer disputes. The audit role gets a complete timeline per shipment for compliance reporting.

Realtime risk surfacing

The dispatcher cockpit calls out shipments at risk — late, route-deviated, anomaly-flagged — in a prioritised list. The dispatcher acts on the risk (reassign truck, call customer, escalate) before it becomes a problem. This was the operational win that drove adoption.

Architecture

[Drivers (mobile-first React PWA)]
       ↕ offline-first sync
[Dispatchers + Ops (desktop React)]
       ↕
[Audit + Executive (read-only views)]
       ↕
[Supabase: Auth + Realtime + Postgres + Storage]
       ↕
[Materialised views for role-specific query patterns]
       ↕
[External integrations: temperature loggers, ERP, customer portal]

We chose Supabase for the auth, realtime, and Postgres in one. It gave us a small operational surface and a clean code path for the offline sync engine.

Key features shipped

• 1:1, 1:N, N:1, N:N shipment topology support throughout the app.
• Offline-graceful sync with conflict resolution on reconnect.
• 5 role-aware dashboards (driver, dispatcher, ops, audit, executive).
• Cold-chain integrity logging with anomaly detection.
• Realtime risk surfacing on the dispatcher cockpit.
• Photo + signature capture per delivery with cloud storage.
• Compliance audit trail queryable per shipment, per truck, per route.
• PWA install so drivers don't need an app-store app.

Outcomes

What we learned

Reality is a hypergraph, not a tree. If you model shipments as point-to-point, you'll fight your data model forever. Spending an extra week on the topology schema up front saved months of edge-case bugs.

Offline-first is a product decision, not an engineering decision. Drivers cannot wait on a spinner. We built the entire data layer around the assumption that the server is unreachable until proven otherwise.

Five roles is the right number. Too few and someone's job is awkward. Too many and the app sprawls. Five maps to the actual organisational shape of mid-size logistics operations.

Cold-chain compliance is the unglamorous win. The temperature logging and audit trail aren't a feature anyone sells. They're the feature that keeps the business out of regulatory and customer-dispute trouble.

Stack rationale

React + TypeScript + Tailwind + shadcn/ui for the front-end — the stack we run for any custom build we'd want to maintain ourselves in two years.

Supabase + Postgres for the backend. Postgres because we needed proper relational modeling for the shipment hypergraph. Supabase because the auth + realtime + storage + functions in one place dramatically reduced operational surface for a small team.

PWA delivery so drivers can install without app-store friction; works in any modern mobile browser. Native iOS/Android wasn't needed for this scope.

Where to go next

If you have a multi-topology, multi-role operations workflow, the same patterns apply. Drop us a note and we'll come back with a clear next step.

For the broader playbook on how we ship operations platforms, see our The AI Development playbook post.