rl-docs-hub

Home · Apps · rl-bank-mvp

---

Fake shop / merchant ecosystem open questions

Status: Draft review checklist for John.

Product boundary questions

1. Should fake shop remain documented as part of rl-bank-mvp for now, or do we want it treated as a separate app/program area in docs hub?
2. Is the primary goal:
   • merchant realism for demos,
   • a reusable merchant platform concept,
   • or both?
3. Should the first merchant experience target a single shop only, or do we want multi-store concepts visible from the start?

UX questions

1. Should the first POS be:
   • iPad web app,
   • installable PWA,
   • Flutter app,
   • or should that remain open until after flow approval?
2. Should the terminal always be the customer-facing payment confirmation device, or do we want the POS to support soft-POS style fallback flows too?
3. How much receipt/order detail should customers see on the bank side versus only on the merchant side?

Data and realism questions

1. Do we want product data to be entirely generated/seeded into our own system from day one?
2. Should merchant catalogue/media be centrally managed or shop-owned in MVP?
3. What minimum order detail matters for realism:
   • total only,
   • line items,
   • item images,
   • receipt-like references?

Architecture questions

1. Should shop/POS logic live initially inside the existing fake-bank backend, or in a dedicated merchant service/repo?
2. Should POS-to-terminal communication be:
   • backend-mediated only,
   • direct local-network pairing,
   • or a hybrid?
3. Do we want merchant APIs to start as REST, GraphQL, or mixed by surface?

Role and auth questions

1. Will merchant users and bank staff/customers share the same identity provider tenant, or should merchant auth stay logically separate?
2. Do we need distinct roles in MVP beyond owner vs cashier?
3. Do we need staff switching between stores/locations in MVP?

Reporting questions

1. Is a recent orders list enough for MVP, or does John want basic merchant dashboard metrics in the first cut?
2. Do we need a merchant-side transaction export/report concept early, or can that wait?

Recommendation on unanswered items

The safest path is to lock only these decisions first:

• docs location / program boundary
• MVP single-store vs multi-store assumption
• initial POS surface direction
• initial backend ownership boundary
• minimum customer-visible payment detail

Everything else can stay editable for another round.