Skip to content
CanCode DevsCanCode Devs
All work

Case study

Coworking & Cafe Operations Platform

In plain English

Tenants order lunch and book rooms from their phone. Staff run cafe POS, kitchen, and billing in one place.

Three surfaces, one API: tenant mobile, staff desktop with POS, and operations backend.

Who it is for

  • Tenant offices who should not call the front desk to order lunch or book a room.
  • Operators, cafe staff, and managers who need POS, kitchen, inventory, and billing in one place.

Problem

Coworking plus an on-site cafe usually means three tools: a membership spreadsheet, a meeting-room calendar, and a separate till. Orders, quotas, and invoices drift.

Tenants should not call the front desk to order lunch or book a room. Staff need POS, kitchen, and inventory that is not a generic spreadsheet.

Solution

We built a Flutter tenant app, a Next.js staff desktop (Electron), and a NestJS API. Tenants order from the cafe against benefit quotas, book meeting rooms against included hours, see billing, and send feedback. Cafe POS takes walk-in cash sales with no office account.

One API keeps app, POS, and back office in sync over Socket.IO. Mobile is tenant-only; kitchen and admin stay on desktop. This is not a full ERP.

Outcomes

Three surfaces, one API: tenant mobile, staff desktop with POS, and operations backend.

Cafe benefits and meeting-hour quotas are data, not a PDF policy. Walk-ins and tenant orders share catalog and inventory.

FlutterNext.jsElectronNestJSMongoDBSocket.IOAWS S3Docker

How it works

Tenant app and staff desktop talking to one API. Cafe POS, bookings, and billing share MongoDB and Socket.IO.
Tenant app and staff desktop talking to one API. Cafe POS, bookings, and billing share MongoDB and Socket.IO.

Tenant order vs walk-in POS

A tenant order uses office quotas; a walk-in POS sale does not.
A tenant order uses office quotas; a walk-in POS sale does not.

What we built

Tenant app

  • Cafe orders

    Account orders priced: benefit quota, then contract price, then catalog.

  • Meeting rooms

    Book against included hours per cycle.

  • Billing and feedback

    Office invoices and tickets from the phone.

Staff desktop

  • Cafe POS

    Walk-in cash sales with no office account; kitchen stock.

  • Kitchen and inventory

    Order status walk with live toasts; low-stock alerts.

  • Admin

    Users, offices, catalog, rooms, billing, reports, and feedback, scoped by office.

How it works

Both clients talk only to the NestJS API. MongoDB holds offices, orders, invoices, and inventory. Socket.IO rooms keep kitchen and POS live without polling.

Account orders require an office. POS walk-ins do not. Pricing for account orders is quota, then contract, then catalog.

Integrations

  • Socket.IO

    Kitchen and POS stay live without polling.

  • AWS S3

    Avatars and uploads.

  • MongoDB

    Offices, orders, invoices, and inventory in one cluster.

Have a similar challenge?

Start a project