CareReach — the spec

CareReach is a marketplace portal that puts private home and health care providers in front of adults who are actively searching for care — either for themselves or for aging parents. Visitors can describe what they need, browse matched providers, and open a direct conversation with a provider, collapsing the gap between someone with an urgent care question and a qualified service that can answer it.

---

Decisions locked

---

The core loop

1. A visitor lands on the portal and is immediately asked two questions: what kind of care they need and who it is for (themselves or a parent).
2. They browse a filtered list of providers that match their stated care type.
3. They open a provider profile and read enough to decide whether to reach out.
4. They send a message directly to the provider through the in-app messaging thread.
5. The provider responds, and together they agree on a consultation call time.
6. The consultation happens off-platform or via a link the provider shares — the portal's job is done when the two parties are connected.

---

v1 scope

In-app messaging between users and providers
A persistent, threaded message inbox accessible to both sides after a user initiates contact with a provider. Lives on a dedicated Inbox screen for both user and provider accounts, with unread-message badges visible on every page.

---

Deliberately later

The following features were considered and held back deliberately — each becomes more valuable once the user base and provider roster are established enough to justify the complexity.

• Search by care type and zip code — geographic filtering needs enough providers per area to return useful results; premature before supply is built.
• Intake form capturing care needs and preferences — powerful, but adds friction on day one; better introduced once the simpler search-and-message loop is proven.
• Provider matching algorithm — meaningful only after the intake form is live and enough form responses exist to train on.
• Provider profiles with rates and availability — rates and live availability require providers to maintain data; onboarding them to this expectation is a v2 conversation.
• Booking calendar and consultation scheduling — calendar integration adds engineering overhead; direct messaging handles scheduling in v1.
• Review and rating system — requires completed engagements to be meaningful; the network needs volume before reviews carry signal.
• Saved favorites and comparison tool — comparison is only useful when the catalog is large enough that users feel overwhelmed choosing; not a day-one problem.

---

Data model sketch

• users — id, name, email, password hash, account type (seeker / provider), created at
• providers — id, user id (FK), business name, care types offered, bio, contact email, created at
• care_seekers — id, user id (FK), care recipient (self / parent), care type interest, created at
• conversations — id, seeker id (FK), provider id (FK), created at, last message at
• messages — id, conversation id (FK), sender id (FK), body, sent at, read at
• care_types — id, label (e.g. "Respite Care", "Personal Care", "Companionship")

---

Screens

• Home / Landing — presents the two entry questions (care type, who it's for) and surfaces provider cards immediately below.
• Provider List — filterable grid of providers matching the visitor's stated care type.
• Provider Profile — single-provider detail page with bio, care types offered, and a "Message this provider" call to action.
• Inbox (Seeker) — list of all active conversation threads initiated by the seeker, with unread indicators.
• Inbox (Provider) — mirror of the seeker inbox, scoped to the provider's incoming threads.
• Message Thread — the live conversation view between one seeker and one provider.
• Account / Sign-up — unified registration and login screen differentiating seeker from provider account type.

---

How to use this document

• Bring it into Mind Palace, where the guided platform and its AI coach pick up from exactly this document and build the product with you step by step.
• Hand it to a developer as the complete v1 brief — scope, data model, and screen list are defined and ready.
• Keep it as the single source of truth while you build, so every decision stays anchored to what CareReach is actually for.