CR Coffee on Magazine Street, New Orleans, at dusk.
All work Case study · CR Coffee

Running four coffee shop locations on one app.

Schedules with shift swaps. Opening and closing checklists. Recipes and training. Team messaging with ack-required announcements. Inventory with supplier-ready order sheets. Push notifications. Four shops, one team — installed on every staff phone.

4retail coffee locations
1 teamcoordinated across every shop
1 appon every staff phone
2024in daily production since

The state before

CR Coffee is a New Orleans coffee company with four retail locations. Like most growing multi-location shops, it had hit the wall where the group text + a shared Google Drive + three different scheduling apps stops scaling. Schedules lived in one app, recipes lived in a folder, training lived in another folder, the manager's clipboards lived on a clipboard. Updating a recipe meant updating it in three places and hoping the right people noticed. New hires onboarded by being handed a stack of paper.

The breaking point was the moment between "we have one shop" and "we have four shops." That's the gap that destroys operations — the systems that worked for one fail silently at four, and by the time you notice, you've lost a week of consistency.

What we built

The Coffee Shop Portal is a multi-tenant Progressive Web App (PWA) — an installable web app that lives on any staff phone like a native app, with no App Store and no IT request — that unifies the eight or nine things a multi-location coffee operation needs to run. It's per-tenant isolated (each shop gets its own database, branding, and access controls), mobile-first (every interaction tested on a barista's phone, not a designer's laptop), and built so that the things that change most often (schedules, recipes, announcements) update once and propagate everywhere.

The state after

New hires onboard with a phone in their hand. A recipe change in the back office propagates to every barista on shift. The opening manager doesn't have to call the closing manager from yesterday to find out what got left undone. Inventory order sheets generate themselves from par-level thresholds — the manager reviews, edits, and sends. The four shops operate as one coordinated team instead of four parallel ones.

Most importantly, the operation runs on infrastructure that the operator controls. There's no SaaS bill that doubles. There's no feature roadmap held hostage by a vendor's quarterly priorities. When something needs to change at CR Coffee, it changes that night.

Stops running your shop out of a group text and a spreadsheet. That was the brief. The Portal is what came out of it.
— Kevin Pedeaux, Founder · CoreRail · Operator, CR Coffee

Lessons we earned the hard way.

The Portal is in its third major architectural iteration. Here's what we got wrong on the first two.

Built for desktop first

The first version had a clean desktop UI and a cramped mobile experience. Baristas live on phones. The mobile-first rewrite came painfully — we'd start from the phone screen now and let the desktop be derivative.

Multi-tenant came late

v1 was effectively single-tenant. When the second shop went live, we discovered every place we'd hardcoded assumptions. The migration to per-tenant database isolation took weeks. Start with multi-tenant architecture from day one.

Push notifications too aggressive

Early push notifications fired for everything. Staff started silencing them, which defeated the point. The current system is opt-in by category with smart batching. We'd ship the granular controls with v1 next time.

Operating multi-location retail or hospitality?

The Coffee Shop Portal is multi-tenant by design. The patterns are battle-tested. Let's talk.

Start a conversation