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