Files
baya-monorepo/product/notes/open-questions.md
T
2026-07-20 01:35:15 +03:30

86 lines
4.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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](../../dev/shared-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](../../dev/shared-working-context/reports/ui-phase-13-report.md) for the
full build record.