create mvp path
This commit is contained in:
hamid
@@ -0,0 +1,85 @@
|
||||
# Open Questions & To-Do Backlog
|
||||
|
||||
[← Product docs home](../index.md)
|
||||
|
||||
From `whatsInYourMind.txt` — things to build, research, or decide. Some are now resolved in the
|
||||
refined data model; marked below.
|
||||
|
||||
---
|
||||
|
||||
## Build / surface backlog
|
||||
|
||||
- **Ticket page** — the admin-readable messaging surface; modeled in
|
||||
[Messaging (ticket system)](../data-model/09-messaging.md) and required by
|
||||
[Messaging & On-Site Emergencies](../business/12-messaging-and-emergencies.md).
|
||||
- **Backoffice / admin** — see [Notifications & Admin / Backoffice](../business/14-notifications-and-admin.md).
|
||||
- **Verify the registration code** — OTP confirmation step in onboarding.
|
||||
- **Rate limiting** — abuse protection on auth/OTP and API.
|
||||
- **Workbox for cache** (maybe) — PWA/offline caching, client-side.
|
||||
|
||||
## Needs research
|
||||
|
||||
- **Terms of Service page** — *(needs research)*.
|
||||
- **Privacy & Policy page** — *(needs research)*.
|
||||
|
||||
---
|
||||
|
||||
## Resolved questions (kept for the record)
|
||||
|
||||
These were the two hardest open questions; both are now **answered** against verified payment
|
||||
research and built into the model.
|
||||
|
||||
- ~~اگر پرداخت قسطی داشته باشیم و طرف اون وسط بخواد کنسل کنه چی میشه؟~~
|
||||
**(BNPL booking cancelled mid-plan — what happens?)** → Resolved. Money always flows
|
||||
`customer ↔ provider ↔ Balinyaar`; Balinyaar calls the provider's revert/cancel/update API and the
|
||||
provider unwinds the customer's installments. See
|
||||
[Q1 — cancellation/refund](../payments/cancellation-and-payout.md) and
|
||||
[the two questions](../data-model/index.md).
|
||||
- ~~BNPL اگر باشه خب پول پرستار رو کی میده؟~~
|
||||
**(Under BNPL, who pays the nurse?)** → Resolved. **Balinyaar** pays the nurse, on its own weekly
|
||||
schedule, from `gross − balinyaar_commission` — identical to a card booking; the BNPL commission is
|
||||
a platform expense, never the nurse's. See [Q2 — who pays the nurse & when](../payments/cancellation-and-payout.md).
|
||||
|
||||
---
|
||||
|
||||
See also the launch-blocking items to confirm with counsel / providers:
|
||||
[research open questions](../research/go-to-market.md) and
|
||||
[data-model open items](../data-model/index.md).
|
||||
|
||||
---
|
||||
|
||||
## Decided — public guest-browse depth (ui-phase-13, 2026-07-19)
|
||||
|
||||
**Question:** how deep should the anonymous (logged-out) web experience go, now that the entire
|
||||
public surface is a bare `/login`?
|
||||
|
||||
Three tiers were framed:
|
||||
- **(a) Landing only** — a marketing page at `/`; zero data, zero new endpoints.
|
||||
- **(b) Landing + static public pages** — (a) plus category/how-it-works/trust content; still zero
|
||||
data (a static i18n category grid, not the live catalog).
|
||||
- **(c) Guest search + public nurse profiles** — read-only anonymous variants of the search-results
|
||||
and nurse-profile screens. Requires **public read endpoints that don't exist today** (search and
|
||||
profile reads sit behind the auth middleware + cookie-bearing `clientFetch`) plus a privacy review
|
||||
of which nurse fields may be shown logged-out (never phone, exact address, or document data).
|
||||
|
||||
**Decision: ship (a)+(b) now; tier (c) is deferred as a REQ-gated follow-up**, not built against
|
||||
placeholder endpoints. Rationale:
|
||||
- (a)+(b) already close the biggest gap — a family can see the brand, the trust story (identity/
|
||||
license/INO/bank verification), the escrow guarantee, and the service categories before creating
|
||||
an account, all with **zero new backend surface**.
|
||||
- (c) is a materially bigger commitment: a new anonymous, rate-limited search read and a
|
||||
privacy-reviewed public nurse-profile shape are backend work with real abuse/PII exposure
|
||||
considerations (scraping, competitor intel, nurse safety) — the kind of decision that shouldn't be
|
||||
made by inferring it from a frontend phase.
|
||||
- What (c) would need, if approved later: an anonymous `nurse_search` read (verified-only invariant
|
||||
preserved, rate-limited, no customer-context fields) and a privacy-reviewed public nurse-profile
|
||||
read (display name, photo, verified-badge state, rating aggregate, service/price rows only — never
|
||||
phone, exact coverage area, or document data). Filed as REQ-066/REQ-067 in
|
||||
[for-backend.md](../../archive/build-chain/working-context/frontend/requests/for-backend.md); guest-search
|
||||
routes and the guest→login handoff at the booking CTA stay unbuilt until those land.
|
||||
|
||||
Implemented as: a public landing rewritten in at `/` (middleware rewrite, not a redirect, so the URL/
|
||||
canonical stays `/`) with hero, static category grid, how-it-works, a trust/verification explainer,
|
||||
a nurse-recruitment CTA, and a footer — see
|
||||
[ui-phase-13-report.md](../../archive/build-chain/working-context/reports/ui-phase-13-report.md) for the
|
||||
full build record.
|
||||
Reference in New Issue
Block a user