Epic: tiered operator modes — bar / bistro / full restaurant #2

New issue

Open

opened 2026-05-10 14:46:18 +00:00 by padreug · 0 comments

padreug commented

2026-05-10 14:46:18 +00:00

Owner

Background

Feedback from DarthCoin (retired IT consultant who
spent years building infra for restaurants) on the early scaffold:

Right now I see [the extension] is more for a simple bar serving
static final items that do not involve any preparation/production.
A restaurant ext is a very important one, but also a lot more
complex.

You can make in 2-3 levels of complexity that can be activated only
when is needed. A simple bar serving coffees and drinks would not
need to see the part of production, just the inventory for example.
A bistro restaurant serving pre-cooked items would need to see the
inventory but also part of the serving process. A full restaurant
will have to see the whole process, from raw material items
inventory, to production, cooking, waiting lines, serving etc.

This is the right mental model. We should not pile complexity on the
operator who just wants to sell coffee — but we should leave a
clear ramp for someone running a full kitchen.

Goals

A single extension that scales from "tiny café" to "full kitchen"
by toggling modes rather than installing different things.
Defaults are dummy-proof: an indigenous operator who just
bought their first smartphone should be able to ship a working
menu without ever seeing the production / inventory / loyalty
surfaces.
Power-user complexity is tucked away, not erased. Toggling on
Bistro or Full mode reveals the relevant CMS panels and API
surfaces.

Proposed modes

            ┌── menu CRUD
   bar      ├── orders + KDS (already shipped)
   ────────┤── thermal printer
   (today)  ├── Lightning + cash settlement
            └── Nostr menu publish (NIP-99)

            ┌── everything in `bar`, plus
   bistro   ├── inventory tracking          → #3
   ────────┤── pre-cooked-items prep flow   → #4 (light)
            └── COGS visibility             → #6

            ┌── everything in `bistro`, plus
   full     ├── raw-material BOMs           → #3
   ────────┤── multi-station kitchen flow   → #4 (full)
            ├── waitstaff floor monitor     → #4
            ├── chef / expo board           → #4
            ├── waiting-line / ETA          → #4
            └── loyalty                     → #5

Mode is a per-restaurant setting (not per-instance) — one LNbits
account can host a café and a full restaurant under different modes.

Children

Each tier's features are tracked separately:

#3 Inventory — raw materials, batches, expiry, decrement on
order, harvest-to-table provenance.
#4 Production / kitchen workflow — beyond KDS: prep stations,
course timing, expo board, floor monitor.
#5 Loyalty / customer fidelity — Nostr-native points.
#6 Cost-of-goods + margin-driven pricing — ties materials
pricing → menu pricing.
#7 Deployment + monetization — how this ships.

Plus:

#1 Printable PDF menu — orthogonal but listed here for context.

Open questions

Where does the mode toggle live? Likely on the restaurant
settings page, with each tier showing a one-line description of
what it unlocks. Picking a tier doesn't delete data from the
higher tiers if downgraded — just hides the UI.
Per-feature toggles vs. tier presets? Tier presets are easier
to communicate. Power users may want à la carte. Compromise:
presets that pre-toggle a set of finer-grained switches the user
can override afterward.
API gating. When a tier is off, do those endpoints return
404 / 403, or do they exist but return empty? I'd lean toward
"exist, return empty" so the webapp can be agnostic.

Acceptance (umbrella)

restaurant.mode column with 'bar' | 'bistro' | 'full',
default 'bar'.
CMS settings page exposes the toggle with descriptions.
Each child issue lands gated by the appropriate tier.
Webapp integration tolerates either tier transparently
(#7-style operational note added to docs/).

References

Telegram conversation 2026-05-09 (DarthCoin, Dr. Shift, AIO).
LNbits ext docs: https://docs.lnbits.com/dev/extensions/

## Background Feedback from [DarthCoin](https://t.me/...) (retired IT consultant who spent years building infra for restaurants) on the early scaffold: > Right now I see [the extension] is more for a simple bar serving > static final items that do not involve any preparation/production. > A restaurant ext is a very important one, but also a lot more > complex. > You can make in 2-3 levels of complexity that can be activated only > when is needed. A simple bar serving coffees and drinks would not > need to see the part of production, just the inventory for example. > A bistro restaurant serving pre-cooked items would need to see the > inventory but also part of the serving process. A full restaurant > will have to see the whole process, from raw material items > inventory, to production, cooking, waiting lines, serving etc. This is the right mental model. We should not pile complexity on the operator who just wants to sell coffee — but we *should* leave a clear ramp for someone running a full kitchen. ## Goals - A single extension that scales from "tiny café" to "full kitchen" by toggling **modes** rather than installing different things. - Defaults are **dummy-proof**: an indigenous operator who just bought their first smartphone should be able to ship a working menu without ever seeing the production / inventory / loyalty surfaces. - Power-user complexity is *tucked away*, not erased. Toggling on Bistro or Full mode reveals the relevant CMS panels and API surfaces. ## Proposed modes ``` ┌── menu CRUD bar ├── orders + KDS (already shipped) ────────┤── thermal printer (today) ├── Lightning + cash settlement └── Nostr menu publish (NIP-99) ┌── everything in `bar`, plus bistro ├── inventory tracking → #3 ────────┤── pre-cooked-items prep flow → #4 (light) └── COGS visibility → #6 ┌── everything in `bistro`, plus full ├── raw-material BOMs → #3 ────────┤── multi-station kitchen flow → #4 (full) ├── waitstaff floor monitor → #4 ├── chef / expo board → #4 ├── waiting-line / ETA → #4 └── loyalty → #5 ``` Mode is a **per-restaurant** setting (not per-instance) — one LNbits account can host a café and a full restaurant under different modes. ## Children Each tier's features are tracked separately: - **#3** Inventory — raw materials, batches, expiry, decrement on order, harvest-to-table provenance. - **#4** Production / kitchen workflow — beyond KDS: prep stations, course timing, expo board, floor monitor. - **#5** Loyalty / customer fidelity — Nostr-native points. - **#6** Cost-of-goods + margin-driven pricing — ties materials pricing → menu pricing. - **#7** Deployment + monetization — how this ships. Plus: - **#1** Printable PDF menu — orthogonal but listed here for context. ## Open questions 1. **Where does the mode toggle live?** Likely on the restaurant settings page, with each tier showing a one-line description of what it unlocks. Picking a tier doesn't *delete* data from the higher tiers if downgraded — just hides the UI. 2. **Per-feature toggles vs. tier presets?** Tier presets are easier to communicate. Power users may want à la carte. Compromise: presets that pre-toggle a set of finer-grained switches the user can override afterward. 3. **API gating.** When a tier is off, do those endpoints return 404 / 403, or do they exist but return empty? I'd lean toward "exist, return empty" so the webapp can be agnostic. ## Acceptance (umbrella) - [ ] `restaurant.mode` column with `'bar' | 'bistro' | 'full'`, default `'bar'`. - [ ] CMS settings page exposes the toggle with descriptions. - [ ] Each child issue lands gated by the appropriate tier. - [ ] Webapp integration tolerates either tier transparently (#7-style operational note added to `docs/`). ## References - Telegram conversation 2026-05-09 (DarthCoin, Dr. Shift, AIO). - LNbits ext docs: https://docs.lnbits.com/dev/extensions/

padreug referenced this issue

2026-05-10 14:48:25 +00:00

Inventory: raw materials, batches, expiry, harvest-to-table #3

padreug referenced this issue

2026-05-10 14:49:04 +00:00

Production / kitchen workflow — prep stations, courses, expo, floor monitor #4

padreug referenced this issue

2026-05-10 14:49:44 +00:00

Loyalty / customer fidelity — Nostr-native points and tiers #5

padreug referenced this issue

2026-05-10 14:50:23 +00:00

Cost-of-goods + margin-driven pricing — derive menu prices from material costs #6