# Blockers — what has to be fixed before this is a real product

Two different kinds of "blocker" here, and both matter:

- **A. The product itself is broken** — a real user would hit a wall or be shown wrong information, with or
  without real money involved.
- **B. The launch gate** — things that must be true before a real stranger with real money is allowed to touch
  this, even on a day when part A is fully fixed.

Effort is a rough size, not a schedule: **S** = small/contained, **M** = a real but bounded piece of work,
**L** = a project of its own.

---

## A. The product is broken or unusable

### Payments
- **A card payment can never actually complete.** The test/demo payment page redirects to a page that
  doesn't exist. Nothing about the money logic itself is wrong — it's the very last step, handing off to a
  real payment provider, that isn't connected. *(Effort: M)*
- **The 30-minute payment countdown can lie.** Booking deadlines are stored without a timezone, so the timer
  a customer sees can silently show hours more time than they actually have, and expire while they still
  think they're fine. *(Effort: S)*
- **Installment (buy-now-pay-later) payments don't work at all.** The behind-the-scenes setup that lets an
  installment plan get created at all is now fixed — but the on-screen wizard still can't be turned on to use
  it: three of its screens (choosing a plan, seeing the repayment schedule, and the "my installments" wallet
  view) call server endpoints that were never actually built, so switching off the fake demo data today would
  make the first screen show an error immediately instead of the outdated-mock failure it shows now. Those
  three endpoints need to be built before this can be turned on for real. *(Effort: S–M, one part fixed, one
  part bigger than first scoped)*
- **Refunds are demo-only today.** The refund screens read fake, disconnected sample data; turning that off
  today would show a refund of the wrong amount (off by a factor of 100) for any real cancellation.
  *(Effort: M)*

### Trust — nurse verification
- **A nurse's verification badge does not reflect reality.** The verified/unverified status shown to
  customers and to the nurse herself comes from a fake demo layer, not the real, already-working
  verification data underneath. A genuinely verified nurse can show as unverified everywhere in the app, and
  vice versa — silently hiding the real "you're not searchable yet" warning a nurse needs to see.
  *(Effort: L)*

### Patient records & visit notes
- **Everything a nurse writes about a visit, and everything a family sees about a patient's care plan, is
  fake demo data.** Nothing typed in today is actually saved, and the real backend behind this expects
  slightly different data than the screens send — so simply "turning the mock off" would break on day one.
  *(Effort: M)*

### Nurse pay
- **A nurse's earnings/payout screens show fake numbers**, hiding four features that already work for real
  underneath. There's also no button anywhere to actually run the "send the money" step — the one
  irreversible action in the whole payout process has no interface at all — and the "paid" status shown to a
  nurse can be wrong (it's set as soon as a payout is linked, not when it's confirmed to have gone through).
  *(Effort: M)*

### Partner / business-center accounts
- **The whole "partner business center" section is fake, with zero real account matching.** Any signed-in
  user who opens it resolves to the same one fake center regardless of who they are, and several of its core
  pages (its own booking list, its own settlement report) don't exist on the server at all yet. This matters
  more than it sounds — see [forgotten-features.md](forgotten-features.md) for why the business plan leans on
  this feature specifically. *(Effort: L)*

### Search
- **Search results aren't de-duplicated nurses — they're raw pricing-option rows.** One nurse with 3 services
  in 3 areas shows up as "9 nurses." The trust information on a result card is also fake, and a nurse who
  isn't verified yet can still be opened directly and shown as "verified" if you know her profile link.
  *(Effort: M)*

### Booking lifecycle
- **A booking whose remaining visits get automatically marked "missed" can get stuck forever** and never
  reach a state where the nurse can actually be paid for the visits she did complete. The "today's visits"
  list nurses see is also unfiltered — it shows a nurse's entire history, not just today. *(Effort: M)*

### Catalog / pricing
- **Outside of the developer's own local setup, there are zero service categories or pricing options
  configured at all**, and there is no admin page to add them — only direct database editing. Deployed as-is,
  every "choose a service" screen collapses to a nearly useless two-step form. *(Effort: M)*

---

## B. Before a real stranger's real money touches this

These hold regardless of whether every item in section A gets fixed first.

1. **Rotate every credential currently committed to the codebase** — the database password, both encryption
   keys, and the API keys for SMS/maps/banking-lookup/bot services. This is a deliberate, known trade made to
   ship a demo fast; it must be undone before onboarding real users. One of these — the key that encrypts
   personal data like phone numbers and addresses — can't just be swapped; changing it requires re-encrypting
   everything already stored under the old one first, so treat that specifically as its own small project,
   not a quick config edit.
2. **Turn off developer/debug mode on the live site.** Right now, the deployed site runs in a mode meant for
   local development. The single biggest consequence: **anyone who knows a person's phone number can read
   their login code directly from a public link** and sign in as them. This has to be closed before real
   strangers can reach the site.
3. **Get real legal review of the Terms of Service and Privacy Policy.** They currently ship as placeholder
   text behind a visible "draft" banner.
4. **Finish the real e-invoicing (مودیان) hookup.** The invoice data and tax math are already correct; the
   actual government-facing integration that registers each invoice isn't wired up yet, and the business plan
   calls this required, not optional, scope.
5. **Obtain "e-namad" certification.** This is a business/paperwork step, not a code change — but a monetized
   Iranian website legally cannot get a real payment gateway without it, so nothing in item 6 below or in the
   card-payment blocker above can go fully live until this exists.
6. **Build a real bank-transfer system for paying nurses.** Every other "fake" system in the app (SMS, maps,
   card payments, identity checks) already has a real version written and just needs real credentials to
   switch on. Paying nurses is the one exception — there is no real version yet at all. Even after everything
   else on this page is fixed, **nurses still can't actually be paid** until this is built from scratch.
