# Open Questions & To-Do Backlog — Balinyaar docs

# 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.

↑ Back to top