98 lines
6.3 KiB
Markdown
98 lines
6.3 KiB
Markdown
# 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.** 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)*
|
||
|
||
---
|
||
|
||
## 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.
|