Zippex

Context

You find the perfect couch on Facebook Marketplace. It's across town, the seller wants it gone by Sunday, and you drive a sedan. Now you're texting friends with trucks, pricing out a U-Haul, or paying a "guy with a van" who might not show. Half the listings on Marketplace and Kijiji never move because moving them is the actual job.

Zippex is a delivery platform for everything local: marketplace pickups, store orders, parcels between friends, urgent documents, and the occasional couch. Fair upfront pricing, no hidden fees, sold in use cases: your world, delivered; small moves, big relief; secure docs when it counts.

Seven apps, one backend

Underneath the product, Zippex is not one app. It is seven, deliberately built without shared tooling: no Turborepo, no Nx, no Lerna. Each owns its dependencies, its build and its deploy.

What they share is a single Firebase project, and that is the whole architecture. Firestore holds orders, users, listings and merchants; the Realtime Database carries live driver GPS; one set of Cloud Functions owns dispatch, payments, expiry and the window lifecycle. No separate API server. That is the only reason five front ends can disagree about presentation and never about what an order is.

Presentation has one reference and no shared package either. The colors, type, motion and components live in a brand system at branding.zippex.app, and each app copies out of it rather than importing from it, which is why builds that ship on their own schedules still look like one company.

Every surface, and who opens it

• zippex.app, the marketing site. Next.js with Framer Motion, on Vercel.
• tracker.zippex.app, the tracking link a recipient opens having installed nothing. A Firebase Hosting SPA.
• merchant.zippex.app, the merchant dashboard: delivery management with Shopify and Square integrations, for stores that want Zippex as their last mile. Next.js.
• developer.zippex.app, the developer portal: hosted API docs, key management, sandbox and usage. Next.js App Router on React, Firebase Auth, Tailwind, MDX docs.
• branding.zippex.app, the Zippex design language: the tokens, motion rules and components every other surface copies from, with the rule that what isn't demonstrated there isn't part of the language.

Three surfaces have no public link: the customer and driver apps, React Native on Expo, shipped as EAS builds with over-the-air updates; the customer web app; and a Remotion app that renders the marketing video.

What happens when you book

Booking places a hold on the card, not a charge: a manual-capture PaymentIntent that only becomes money when the delivery completes. If twenty minutes pass and nobody has accepted, the order expires on its own, the hold is released in-process, and the customer is offered a scheduled window instead. The release only ever touches an authorization that has not captured, so an order nobody accepted can never take a payment.

Six windows a day

The fix for an empty marketplace is not more notifications, it is commitment. Drivers sign up for the same six two-hour slots customers book, one shift document per driver, per date, per slot. Matching the picker exactly turns coverage into a count per slot, and a count is something you can act on.

An order carries the ids of the drivers committed to its slot and rings them first, then broadcasts to every eligible driver. Committed-only dispatch was rejected outright: with one or two drivers signed up, an uncovered slot would just expire, punishing the customer for a supply problem. No-shows get a nudge 30 minutes before the slot and a recorded miss five minutes after, and then a founder decides. Automatic strikes were rejected on the rules, not on sentiment: BC's platform-worker regulations require notice before you remove someone's access to work, so a script cannot be the thing that does it.

Sweeps that heal instead of scripts that patch

"Online" has to mean the app is alive, because dispatch targets online drivers. For a while it didn't: drivers sat online as no-signal zombies whose apps had died days earlier, and every order paged them anyway.

A liveness job now reads the freshest of three signals, a GPS fix, a heartbeat, or a location-task timestamp, stamps a driver who has none, and flips them offline after 45 minutes of silence. The stamp clears the moment any signal returns. Expiry and liveness are both sweeps rather than one-off cleanup scripts, deliberately: a script fixes the drivers who are stale today, a sweep fixes every one that appears after the deploy too, including those from builds still in the fleet that emit no heartbeat.

Pricing you can argue with

Every option is priced side by side before you commit: express when it is urgent, pooled when it can wait, a car for packages, a truck for the bulky stuff. Each shows its window and its carbon impact, computed per kilometre per vehicle type, so the cheaper choice usually reads as the greener one too.

The marketplace problem

Marketplace deals are the sharpest edge. Peer-to-peer commerce in Canada is full of scams, ghosted pickups and "showed up, item was gone" stories, and the missing piece was never logistics. It was somebody honest standing between buyer and seller. Zippex handles the pickup, the delivery and optional payment between strangers, and photos at both ends mean nothing goes missing without a record.

Every delivery is a small contract between strangers that gets honored, and every honored contract makes the next one easier to start. That compounding is the whole business.

Under the hood

The mobile apps are React Native with Expo, Redux Toolkit for state, Stripe for payments and payouts, Expo push for notifications. The web surfaces are Next.js with Tailwind. Everything sits on one Firebase project, with Google Maps for distance and directions.