aiolabs/restaurant
8
0
Fork 0
Code Issues 11 Pull requests Projects Releases Packages Wiki Activity Actions

Deployment + monetization — review LNbits docs and pick a model #7

New issue
Open
opened 2026-05-10 14:53:49 +00:00 by padreug · 0 comments
padreug commented 2026-05-10 14:53:49 +00:00
Owner
Copy link

Background

Dr. Shift dropped two LNbits docs links worth
working through before this extension graduates from "scaffold in our
own monorepo" to something other operators can install:

DarthCoin's adjacent encouragement:

keep in mind that you can sell this extension. this is not a regular
extension. and many restaurants would love it.

The bars could use perfectly fine just a Zeus POS… but a complex
restaurant where is coming Gordon Ramsay will need something
different. Think in the future.

So this issue is the operations / go-to-market track: how does the
restaurant extension actually reach the operators DarthCoin is
imagining?

Decisions to make

1. Distribution

LNbits supports several extension shapes:

  • Manifest-listed in the official catalog. Anyone can enable from
    their LNbits admin UI in one click. Source lives on a public git;
    LNbits pulls a known release tag.
  • Self-hosted private extension. Operator points their LNbits
    config at our git URL.
  • Bundled in a custom LNbits deployment (à la AIO's nix flakes).
    Already what we do internally.

We probably want all three. Pick a default for the public release
and document the others.

2. Versioning + release cadence

  • Tag releases? Use semver?
  • Are LNbits's manifest-listing requirements documented (signed
    release? specific manifest schema)? See the docs.
  • How do we keep the dev branch (main) usable while still cutting
    stable tags?

3. Pricing / monetization

The LNbits monetization docs cover how an extension can charge for
itself. Read and decide between:

  • Free / open (like most LNbits extensions).
  • Paid one-time install (LNbits has primitives for this).
  • Pay-per-paid-order rake (e.g. the operator pays a tiny % per
    settled order to a fixed pubkey — automated via LNbits
    internal transfers).
  • Hosted SaaS (we run instances; charge for support / hosting).
  • Support contracts (free extension, paid service tier).

DarthCoin's frame — "this is not a regular extension" — and the
fact that we're building real production features (#3–#6) suggest
some non-trivial monetization is justified, especially for the
Bistro / Full tiers (#2).

4. Trial / onboarding for Bar tier

Even if Bistro / Full are paid, Bar should probably stay free
forever. The whole point of Bar (per #2) is reaching the indigenous
operator who can't pay a SaaS bill but does run a tiny café. Lock-in
of a paid tier kills that mission.

Concrete flow: Bar = free, Bistro / Full = pay-to-unlock (model TBD).

5. Brand / docs / landing surface

  • A description.md worthy of the LNbits catalog (we have a stub).
  • Tile image (we have a placeholder; #1 stretch covers PDF assets,
    this issue should cover branding too).
  • A README aimed at operators, not contributors.
  • Demo video / screencast.

6. Support channel

  • Issues here in aiolabs/restaurant?
  • A dedicated Telegram / Nostr channel?
  • LNbits community Discord?

Action items

  • Read both docs end-to-end.
  • Write a follow-up note in docs/deployment capturing the
    decisions above. ADR-style — record the alternatives weighed
    so future contributors don't relitigate.
  • Open follow-up issues for any concrete work the docs surface
    (e.g. "add release workflow to publish tags," "wire up
    monetization payment flow," etc).
  • Decide cutoff between free Bar and paid Bistro / Full per #2,
    and document in docs/deployment.

See also

  • #1 — PDF menu (a feature operators will want; useful to gauge
    willingness-to-pay).
  • #2 — tiered operator modes (the natural cutoff line for any
    paid-tier strategy).
  • #3, #4, #5, #6 — the value props for the paid tiers.

References

  • LNbits dev docs (extension deployment + monetization) — see links above.
  • Telegram conversation 2026-05-09 (Dr. Shift, DarthCoin, AIO).
## Background [Dr. Shift](https://t.me/...) dropped two LNbits docs links worth working through before this extension graduates from "scaffold in our own monorepo" to something other operators can install: - **Extension deployment** — https://docs.lnbits.com/dev/extensions/ - **Monetization** — https://docs.lnbits.com/dev/extensions/monetization DarthCoin's adjacent encouragement: > keep in mind that you can sell this extension. this is not a regular > extension. and many restaurants would love it. > The bars could use perfectly fine just a Zeus POS… but a complex > restaurant where is coming Gordon Ramsay will need something > different. Think in the future. So this issue is the *operations* / *go-to-market* track: how does the restaurant extension actually reach the operators DarthCoin is imagining? ## Decisions to make ### 1. Distribution LNbits supports several extension shapes: - **Manifest-listed in the official catalog.** Anyone can enable from their LNbits admin UI in one click. Source lives on a public git; LNbits pulls a known release tag. - **Self-hosted private extension.** Operator points their LNbits config at our git URL. - **Bundled in a custom LNbits deployment** (à la AIO's nix flakes). Already what we do internally. We probably want all three. Pick a default for the public release and document the others. ### 2. Versioning + release cadence - Tag releases? Use semver? - Are LNbits's manifest-listing requirements documented (signed release? specific manifest schema)? See the docs. - How do we keep the dev branch (`main`) usable while still cutting stable tags? ### 3. Pricing / monetization The LNbits monetization docs cover how an extension can charge for itself. Read and decide between: - **Free / open** (like most LNbits extensions). - **Paid one-time install** (LNbits has primitives for this). - **Pay-per-paid-order rake** (e.g. the operator pays a tiny % per settled order to a fixed pubkey — automated via LNbits internal transfers). - **Hosted SaaS** (we run instances; charge for support / hosting). - **Support contracts** (free extension, paid service tier). DarthCoin's frame — "this is not a regular extension" — and the fact that we're building real production features (#3–#6) suggest some non-trivial monetization is justified, especially for the Bistro / Full tiers (#2). ### 4. Trial / onboarding for Bar tier Even if Bistro / Full are paid, Bar should probably stay **free forever**. The whole point of Bar (per #2) is reaching the indigenous operator who can't pay a SaaS bill but does run a tiny café. Lock-in of a paid tier kills that mission. Concrete flow: Bar = free, Bistro / Full = pay-to-unlock (model TBD). ### 5. Brand / docs / landing surface - A `description.md` worthy of the LNbits catalog (we have a stub). - Tile image (we have a placeholder; #1 stretch covers PDF assets, this issue should cover branding too). - A README aimed at operators, not contributors. - Demo video / screencast. ### 6. Support channel - Issues here in `aiolabs/restaurant`? - A dedicated Telegram / Nostr channel? - LNbits community Discord? ## Action items - [ ] Read both docs end-to-end. - [ ] Write a follow-up note in [[docs/deployment]] capturing the decisions above. ADR-style — record the alternatives weighed so future contributors don't relitigate. - [ ] Open follow-up issues for any concrete work the docs surface (e.g. "add `release` workflow to publish tags," "wire up monetization payment flow," etc). - [ ] Decide cutoff between free Bar and paid Bistro / Full per #2, and document in [[docs/deployment]]. ## See also - #1 — PDF menu (a feature operators will *want*; useful to gauge willingness-to-pay). - #2 — tiered operator modes (the natural cutoff line for any paid-tier strategy). - #3, #4, #5, #6 — the value props for the paid tiers. ## References - LNbits dev docs (extension deployment + monetization) — see links above. - Telegram conversation 2026-05-09 (Dr. Shift, DarthCoin, AIO).
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
signer-abstraction
feat/restaurant-by-slug
v0.1.0
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
aiolabs/restaurant#7
No description provided.