baya-monorepo/product/notes/open-questions.md

Open Questions & To-Do Backlog

← Product docs home

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) and required by Messaging & On-Site Emergencies.
• Backoffice / admin — see Notifications & Admin / Backoffice.
• 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 and the two questions.
• 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.

---

See also the launch-blocking items to confirm with counsel / providers: research open questions and data-model open items.

---

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; 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 for the full build record.