create mvp path

mvp/forgotten-features.md

@@ -0,0 +1,88 @@
+# 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.