CentralPass

Marketplace apps own the customer, the data and a slice of every order.

A cafe on Uber Eats gets orders, but it also gets a commission taken off each one, a customer it never learns the name of, and a menu it does not fully control. CentralPass exists to give the venue those three things back. Each venue gets a website under its own brand and domain, payments into its own Stripe account and its own customer records, while the operational core underneath (API, owner portal, staff dashboard, printer bridge) is the product I built and reuse.

Customer journey

Website, menu, ordering, checkout and bookings

Operations

Live order queue, status flow and availability

Administration

Menus, hours, offers, customers and reporting

Venue boundary

Separate deployment, database and configuration

Caffe Primo Firle is the first production proof.

These interfaces are from the CentralPass deployment built for Caffe Primo Firle. Customer and order identifying information was excluded from the images on purpose.

What several months of building actually consisted of.

None of this is a template, a no-code tool or a wrapper around someone else's ordering product. Each piece below is a system I designed, wrote, tested against a real service and deployed, and each one had to keep working when the piece next to it changed.

1. The storefront. A React and Vite site per venue, with menu browsing, modifiers, pickup ordering, checkout and bookings, built to the venue's brand rather than to a CentralPass look.
2. The API and data model. Node and Express on PostgreSQL: menus, modifiers, orders, customers, offers, opening hours, venue settings and role based access, with schema migrations that run before every deploy.
3. Payments. Stripe checkout with the payment confirmed server side by webhook before an order is allowed into the staff queue. The browser is never trusted to say that money arrived.
4. The staff queue. A tablet first dashboard, packaged with Capacitor, that receives new orders over Socket.io, moves them through preparation and marks items sold out for every other screen in real time.
5. The printer bridge. A small Node service that lives beside the thermal receipt printer at the counter, takes jobs from the hosted API and prints them, so a cloud outage or a flaky cafe network degrades gracefully instead of silently losing tickets.
6. The owner portal. Menus, hours, offers, customer records, reporting and time clock workflows, so the owner can run the venue without calling me.
7. Per venue infrastructure. Each venue gets its own Railway project, database, R2 storage and configuration. Onboarding a new venue is a repeatable deployment, not a fork.

How the pieces connect.

1. Venue storefrontReact and Vite experience adapted to each brand and customer journey.
2. Platform APINode, Express, role-based access, business rules, webhooks and Socket.io events.
3. PostgreSQLMenus, modifiers, orders, customers, offers, hours and venue settings.
4. OperationsStaff queue, owner administration and the local receipt-printer bridge.

Decisions made for a busy service, not for a demo.

1. Use real-time events where latency matters. Socket.io pushes new orders, status changes and sold-out updates across customer, staff and owner interfaces.
2. Keep uploads off ephemeral compute. Menu images stream to Cloudflare R2 instead of living on a Railway container that can be replaced.
3. Migrate before every deploy. The production start path fails fast if the PostgreSQL schema cannot be updated safely.
4. Protect venue ownership. Each client retains its domain and Stripe account, while credentials remain outside public front ends and source control.

Web, cloud, data and hardware in one product.

Frontend

React, Vite, Zustand, Capacitor

Backend

Node.js, Express, Socket.io

Data and payments

PostgreSQL, Stripe

Infrastructure

Railway, Cloudflare R2

No credentials or internal administration links appear in this public case study.