Home · Apps · rl-bank-mvp
Fake shop / merchant ecosystem MVP scope
Status: Draft, recommended MVP boundary.
Goal of MVP
Prove one end-to-end believable merchant flow:
- merchant has a fake shop with products
- cashier builds basket in an iPad-style POS
- POS sends checkout context to terminal
- customer pays with fake-bank credential
- order/payment result is visible to merchant
- fake-bank customer activity reflects the purchase
If that works cleanly, the ecosystem is already demo-powerful.
In scope
Merchant setup
- single-merchant or low-complexity merchant model
- one or more shop/store records, but simple enough for a small demo setup
- basic product catalogue with image, name, and price
POS
- iPad-first layout direction
- product grid/list browsing
- basket creation and modification
- checkout initiation
- visible payment status
- simple completed sale confirmation
Terminal integration
- send amount + checkout context to terminal
- show terminal status in POS
- receive approve/decline/cancel/error result
- allow retry after non-success outcomes
Merchant history
- recent orders list
- recent payment attempts list
- basic order detail view
Bank-side linkage
- authorized payments create believable fake-bank transaction/activity entries
- merchant display label is propagated where possible
Explicitly out of scope for MVP
Merchant operations that can wait
- inventory counts and stock deductions
- discounts, promos, coupons
- returns and refunds
- end-of-day closeout
- settlements and payout reporting
- receipts by email/SMS
- kitchen display, table service, or delivery workflows
- multi-terminal fleet orchestration beyond basic pairing/context passing
Technical choices to defer
- whether POS is web-only, Flutter, React Native, or native iPad app
- whether shop backend is a new repo/service or a slice inside existing bank backend initially
- final sync model between POS and terminal
- final auth provider/role structure for merchant users
Suggested MVP shape
Smallest believable slice
- 1 merchant org
- 1 shop/store
- 10-30 products
- 1 iPad POS surface
- 1 physical terminal prototype
- 1 fake-bank customer/card flow
- 1 happy path plus a small set of failure paths
Happy path to optimize first
- cashier opens POS
- cashier adds products
- cashier taps checkout
- terminal displays amount
- customer taps fake-bank token/card
- payment approved
- POS shows paid order
- customer history shows merchant payment
Failure paths worth including in MVP
- declined payment
- cancelled payment
- timed out payment
- terminal temporarily unavailable
Recommended implementation posture
For MVP, I would prefer:
- simple state transitions over rich workflow engines
- clear order/payment records over premature reporting systems
- single-store assumptions where they reduce complexity
- merchant realism over advanced merchant admin features
Exit criteria for MVP
The MVP is successful when John can review or demo a flow where:
- the merchant side looks coherent
- the terminal feels integrated rather than bolted on
- the fake-bank side reflects the transaction convincingly
- the system is good enough to discuss next-step enhancements instead of debating basic shape