White-Label Restaurant Platform

Custom apps cost more than most independent restaurants make in a year, so they end up on third-party marketplaces: high commissions, no customer data, and a menu that looks like everyone else's. The alternative, forking a template app per client, is how white-label vendors drown in maintenance.

I wanted to know if one codebase and one backend could serve many restaurants, each with a genuinely separate app under their own name, without copying code for every new client.

Every restaurant is a tenant: a row in the database plus a brand file with its name, colors, icon, and feature flags. The customer apps, the dashboard, and the API are each one codebase serving every tenant. Shipping a fix to all restaurants is one commit. Onboarding a new one is a config file and a build, not a new project.

The dashboard is where a restaurant lives during service. New orders land on a live board and move through accepted, preparing, and ready; the kitchen screen shows the same tickets by station with a timer on each. Around that sit the menu editor, customer records, reservations, rewards, marketing, reviews, and analytics.

A guest downloads the restaurant's own app or opens its web ordering page. Menu, ordering, pickup or delivery, rewards, gift cards, reservations, and messages, all themed to that restaurant from the brand file the app fetches at launch. Sign-in is a phone number and a code, because nobody remembers a password for a pizza place.

Every tenant-owned table carries a tenant id, and Postgres row-level security enforces it, so a request can only ever see its own restaurant's rows. Tenant identity comes from the signed-in token or the app's API key, never from a request parameter. Money is integer cents everywhere and order totals are always computed on the server.

Payments run through Stripe Connect, so each restaurant is paid into its own account and the platform never holds funds or touches card data. An order is written before payment and only becomes placed when Stripe's webhook confirms it, handled idempotently so a retry can't create a second order. Push goes out over APNs for app users and falls back to SMS for web guests.

The iOS build pipeline is the part most white-label products get wrong. Here the Xcode project is generated from a config file per tenant, built and submitted with fastlane under the client's own developer account, and only the app name, icon, bundle id, and API key are baked in. Theme and feature flags come from the API at launch, so most changes never need an App Store release.

System design and the written architecture document, the data model and migrations, the API, both Next.js apps, the native iOS app, the per-tenant build pipeline, payments, notifications, the operator tooling, tests, and the deployment runbook. Built with AI assistance as a deliberate part of the workflow, which is how one person ships this much surface area.

Everything on this page is real software running against seeded demo tenants. Ember & Oak and Urban Greens are invented, and so are their customers and orders. The next step is the same one every product faces: a first restaurant.

Catalyst Art taught me to build for one client. This taught me to build for many at once without building for any of them. Every table, every query, every screen had to be designed so that the second, tenth, and fiftieth restaurant cost nothing extra. Getting the security model into the database itself, rather than trusting application code to remember, was the single decision that made the rest possible.

It also made me respect the boring choices: one API, one database, integer cents, and a payment flow that refuses to believe the client. Those are what let a solo developer sleep.