# TODO / Backlog

## Rethink the tier model — decouple tier from business type
**Goal:** tiers should NOT be tied to a kind of business. Which "tier" (and whether a
client's site is self-hosted or runs on Google's free services) is a decision made
**between me and the client**, case by case — not something baked into a demo.

Implications to work through:
- **Demos are stack-agnostic starters.** Each demo page is just an example business with
  *no committed stack* — it shows what the client could get (website + booking / orders /
  lead capture), not "Tier A = Google" vs "Tier B = self-hosted". Drop tier/stack labels and
  jargon (self-hosted, Cal.com, Google-Stack, "≈ 0 €") from the public-facing demos &
  chooser. (Chooser already reworded 2026-06-25; the demo *pages* still carry stack framing —
  tier-a is Google-Kalender-themed, tier-b is self-hosted/Datenschutz-themed. Neutralise later.)
- After a client signs, **I decide hosting**: self-host the page on the homelab, or stand it
  up on the client's free Google account. The CRM already has `tier` + `stack_notes` columns
  to record that decision per client.
- Revisit the `Clients.tier` field semantics: keep A/B as an internal effort/price band, or
  replace with something hosting-agnostic (e.g. `hosting = google | selfhosted`, `plan = …`).
- Onboarding form + workflow currently ask for Tier A/B — realign once the model is settled.

## Other
- Harden n8n auth: compose still has deprecated `N8N_BASIC_AUTH_*` with password `password`
  (legacy/ignored by modern n8n owner-login). Confirm the owner account is strong; remove the
  dead env.
- Orders: the pizzeria demo posts orders into the `Leads` tab via the lead-intake webhook as a
  stop-gap. Build a proper **Orders** flow + sheet tab (items, total, mode, status) when the
  order-management product is real.
- Booking-sync workflow (Tier-B Cal.com webhook + Tier-A Google Calendar poll) — next up.