Bytesnitch

Case study

Multi-sided logistics platform

A multi-sided logistics platform for three audiences. Authentication is built. Booking, tracking, and payment are modelled in the database and are not built.

Illustrative example of a multi-sided logistics platform showcase with customer portal, operations console and delivery partner app.

Summary

A white-label logistics foundation for three audiences. What is implemented is the design shells and full authentication. Pricing, booking, providers, tracking, and pay are modelled in Postgres and are not built.

Role. The notes record an authentication foundation for customer, partner, admin, and manager. Booking, airway bills, and provider adapters are not part of what shipped.

Outcome. Sign-in covers customer, partner, admin, and manager, with manager finance fields stripped. Access tokens last 15 minutes. Refresh tokens are hashed and rotated. Reuse of a revoked token revokes the family. The web client uses an httpOnly cookie and an X-Requested-With header. Mobile keeps the refresh token in secure storage. Postgres already models orders, tracking, and payments, and those services are not built.

The business gap

The gap

Three audiences need separate access before booking, tracking, or payment can be treated as live. The schema already names those later services.

Why it was built

The notes describe customer, partner, and operator shells, and a database that already models orders, tracking, and payments, with only authentication implemented.

How the build closed it

A Vite SPA with three audiences, plus Expo for customer and partner, talks to Fastify authentication only. One user record covers CUSTOMER, PARTNER, ADMIN, and MANAGER, and manager finance fields are stripped. The access token lasts 15 minutes. Refresh tokens are hashed and rotated; reuse of a revoked token revokes the family. The web httpOnly cookie requires the header recorded in the low-level notes. Mobile refresh tokens sit in secure storage. Postgres models orders, tracking, and payments. Services besides authentication do not exist. Console email stands in until SMTP has a host. Booking, rates, tracking, and pay stay outside the shipped scope.

Architecture

The source notes describe this system as a graph, not as a picture file. The diagram below is that graph: every box and every link is a node or an edge from the notes.

Vite SPAClientExpo customer andpartnerClientFastify authAPIPostgresDataConsole emailExternal
Three-audience authentication. Booking, rates, tracking, and pay are not shipped.
  • Client
  • API
  • Queue
  • Data
  • External

Parts

  • Vite SPA: Public, app, partner, and admin shells.
  • Expo customer and partner: Separate app variant. Refresh token in secure storage.
  • Fastify auth: Route, then auth service, then Prisma. Authentication only.
  • Postgres: The domain schema exists. Services besides authentication do not.
  • Console email: SMTP throws until a host is configured.

Connections

  • Vite SPA to Fastify auth: cookie and header.
  • Expo customer and partner to Fastify auth: bearer and rotate.
  • Fastify auth to Postgres: user and refresh token.
  • Fastify auth to Console email: reset link.

High-level design

  • A Vite SPA with three audiences, plus Expo for customer and partner, talks to Fastify authentication only.
  • Postgres already models orders, tracking, and payments. Those services are not built.
  • The web client sends a cookie and X-Requested-With. Mobile sends a bearer token and rotates refresh tokens.

Low-level design

  • One user record covers CUSTOMER, PARTNER, ADMIN, and MANAGER. Manager finance fields are stripped.
  • Access JWT is 15 minutes. Refresh tokens are hashed and rotated. Reuse of a revoked token revokes the family.
  • The web httpOnly cookie requires the header X-Requested-With: ShipLane. Mobile refresh tokens sit in secure storage.

Infrastructure and services

  • Postgres. The domain schema exists. Services besides authentication do not.
  • Console email. SMTP throws until a host is configured.

Tech stack

  • Fastify logoFastify
  • Prisma logoPrisma
  • PostgreSQL logoPostgreSQL
  • Vite logoVite
  • React logoReact
  • Expo logoExpo
  • Zod logoZod
  • argon2

Logos are Simple Icons shipped with this site. Where a brand mark is unavailable, the name is shown on its own.

Client review

Authentication is solid and the unfinished booking and tracking services are called out openly. We always knew what was ready versus still planned.

Platform lead, logistics

Client testimonial

Shippers and carriers finally share one login story. The roadmap gaps were honest, which made planning the next phase straightforward.

COO, multi-sided logistics

Constraints in the source

  • Prisma already models orders, tracking, and payments. Services besides authentication do not exist.
  • Do not present booking, airway bills, or provider adapters as shipped.

All projectsDiscuss a projectServices