CentralPass

Give venues a direct connection to their customers.

CentralPass gives a venue its own branded ordering channel and connected operational tools. Customers order through the venue’s website, payments go into its Stripe account, and staff manage the order through preparation. The shared platform underneath includes the API, owner portal, staff dashboard and printer bridge.

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

In use at Caffe Primo Firle.

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

From customer checkout to the receipt printer.

I designed, implemented and deployed the application and its integrations over several months. My work spans the customer interface, backend data model, payments, staff tools and the local printer service.

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, connecting the hosted order system to the venue’s printer. Outage recovery needs to be evaluated across the queue, network and printer together.
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.

Scroll sideways to see the whole diagram

The printer was the hard part, and not for the reason I expected.

Everything else in the system is a web service talking to another web service. The receipt printer is a physical object sitting on a restaurant's own network, and it turned two assumptions into bugs before it printed a usable docket.

1. The cloud cannot reach into a restaurant. The printer answers on a private address that only exists inside that building, and exposing it to the internet so the server could dial it would be the wrong fix. I reversed the direction instead: a small agent runs on a machine in the venue and connects outward to ask whether there is anything to print. Nothing inbound, no port forwarding, no static public address. It speaks Star's CloudPRNT protocol in software, which is what lets an ordinary receipt printer that has never heard of CloudPRNT be driven by it.
2. The printer lied about its own width. Its self test page reported 40 columns. It wraps at 33. Every dollar amount landed on the line below the item it belonged to, and the venue name split in half. The fix was to stop trusting the self test: the app prints its own width ruler, and you read the real number off the paper before registering the printer.
3. A power cut silently stops printing. A printer left on plain DHCP comes back with a different address, the agent keeps asking politely, and no error appears anywhere a staff member would look. It now needs a reserved address at setup, and that is written into the install steps rather than left as folklore.

Print jobs move through queued, offered, downloaded and completed, so a docket that was fetched but never confirmed is visible rather than lost.

Designing for restaurant service.

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.