# 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 - **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.**~~ **Fixed (phase 08)** for the customer-facing flow: the cancellation preview, the cancel confirmation, and the refund-status screen now read the real backend, and the ×100 percent-display bug is gone. The **admin refund console** (preview / retry / reject) is still mocked — those three endpoints don't exist on the real server yet (see `mvp/fix-plan.md` follow-ups). ### Trust — nurse verification - ~~**A nurse's verification badge does not reflect reality.**~~ **Fixed (phase 09).** The badge everywhere (search, nurse's own profile, admin case review) now reads the real verification data; the admin whole-verification approve/reject actions got real endpoints (they previously 404'd). ### 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)* ### 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)* --- ## 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.