hamid
6.1 KiB
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, 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.