# Forgotten features — gaps that should probably be in the MVP plan

This is not the full backlog. It's a short, opinionated list of things that are easy to lose track of because
they don't show up as a bug in the app (there's nothing to click and see broken) — they're missing consoles,
missing channels, or missing business steps that the product's own plan implies are needed, but that aren't
clearly assigned to anyone right now.

---

## Worth reconsidering for MVP

**Nurses have no real way to get paid.** This is also in [blockers.md](blockers.md), but it's worth
separating out as a planning gap, not just a bug: every other "fake" integration in this app (SMS, maps, card
payments, identity checks) already has a real version written and waiting for credentials. Paying nurses does
not — there is no real bank-transfer integration at all, for any provider. A home-nursing marketplace whose
nurses can't be paid isn't really an MVP yet, so this deserves to be sized and scheduled as new work, not
discovered late.

**Nobody can actually approve a nurse, even after admin login gets fixed.** The nurse-verification approve/
reject buttons in the admin console point at server actions that don't exist yet. Fixing the admin-permission
bug (the #1 item in blockers.md) will not make this work — it's a second, separate piece of missing work,
easy to assume is "included" in the RBAC fix when it isn't.

**Nobody can review a refund before it happens.** Today, an admin action that creates a refund also executes
it in the same step — there is no preview/approve/reject step, the way there is for other sensitive actions.
For a marketplace holding customer money in escrow, having no human-review gate before money moves back out
is worth a second look before launch, not just "eventually."

**There's no way to confirm whether a nurse payout actually succeeded or failed.** The system can generate a
payout batch, but there's no console action to record "the bank transfer bounced" and reconcile it. Combined
with the point above about there being no real bank-transfer system yet, payouts as a whole need a fresh look
before this ships.

**Partner business centers — the business plan's stated fast, legal path to market — are 100% fake today**,
with no real tenancy, no real onboarding, and several of the pages a partner would need (their own booking
list, their own settlement report) not built server-side at all. This is flagged as a blocker, but it's worth
naming explicitly as a *feature* gap too: if the go-to-market plan depends on partnering with already-licensed
nursing centers, someone needs to own building the actual partner-facing product, not just unblocking the
admin side of it.

**Only in-app notifications exist — no SMS or push.** That's a fine trade in general, except two flows are
genuinely time-boxed: a nurse has roughly a day to respond to a booking request, and a customer has 30 minutes
to pay once accepted. If nobody has the app open when that window opens, they simply miss it, silently. Worth
a deliberate call on whether at least these two moments need a text message, rather than leaving it as "no
SMS/push, full stop."

**There's no way to search for a nurse by name.** Only category, city, gender, and price filters exist. Minor
on its own, but combined with the fact that search results aren't de-duplicated yet (see blockers.md), a
returning customer who wants to rebook "the nurse she had last time" currently has no reliable way to find her
again by name.

**The legal/compliance items already called out in blockers.md** — real Terms & Privacy copy, the
مودیان e-invoicing hookup, and e-namad certification — are as much "features not yet built" as they are
blockers. Listed here again only so they don't get read as pure security/ops cleanup and quietly deprioritized
relative to product features.

---

## Deliberately cut — already decided, listed only so they don't get re-litigated

Everything below was already, explicitly ruled out of MVP scope by an earlier product or engineering decision.
None of it is "forgotten" — it's recorded here as a single short list so a planning conversation doesn't
accidentally re-open one of these by mistake.

- **"Nurses near me" (GPS-radius map search)** — coverage stays named-district-only, by design, permanently.
- **Recurring / subscription bookings** — one-off bookings only for now.
- **Company / organization accounts** (a business paying for multiple employees' care) — not modeled yet.
- **Holiday/surge pricing, and a distinct "daily companionship" pricing tier** — out of scope per the pricing
  business rules.
- **Two-way, double-blind reviews** — reviews are one-way (customer → nurse) only, by design.
- **Automated fraud scoring** — manual suspension plus support alerts cover this for now.
- **Automated license/credential lookup with the medical licensing authority** — manual verification is the
  intended MVP path; no public lookup API is confirmed to even exist yet.
- **In-app calling/dialer for emergencies** — the emergency contact is a plain phone-dial link on purpose, not
  a built-in calling feature.
- **Offline/installable app mode** — marked optional from the start.
- **Scaling infrastructure** (a shared cache, a dedicated search engine, an analytics warehouse) — today's
  single-server setup is correct at MVP scale; each has a specific, measurable trigger for when to revisit it,
  not a date.
- **An automated holiday calendar feed** — a yearly manual top-up is an acceptable trade for now.
- **Collecting a customer's national ID** — deliberately never gated on this, by design.
- **On-demand/instant nurse payout, or a different payout schedule per nurse** — one fixed weekly cycle for
  everyone is the MVP design.
- **Automated recovery of clawed-back money beyond simple netting against the next payout** — the simple
  version covers MVP.
- **A true desktop-width layout** — the phone-width layout is the whole app's deliberate design for now.
- **Partner centers signing themselves up online** — centers are onboarded manually for now, separate from the
  partner-center product gap called out above.
