# Baby Nurt — MVP & GTM Master Blueprint v0 (pre-council, evidence-gated)

Authored 2026-07-30 `[F]` as master synthesist, per `00_ADMIN/FABLE_MASTER_BLUEPRINT_BRIEF.md`. **This document decides nothing.** Niche selection is deferred to P3 (`00_ADMIN/DECISIONS.md` D-005) and the P2 council has not run. Every load-bearing statement carries one of three tags:

- **[E]** — directly captured evidence, with the artifact path.
- **[H]** — reasonable working hypothesis, untested, standing for council attack.
- **[GAP]** — missing evidence, or a decision reserved for the council/sponsor.

## 1. Executive decision frame

**Problem space [E].** The charter's north-star question: the smallest, defensible, trust-first care-service wedge in Poland that can earn supply and demand, learn quickly, and expand credibly across child, elder, and pet care without becoming a generic low-trust listings site (`PROJECT_CHARTER.md`). The captured market shows a concrete trust vacuum: Polish surfaces use "sprawdzona" (*vetted*) as a landing-page label while either disclaiming verification in writing or stating no mechanism at all (`01_RESEARCH/evidence/B1-poland-direct-platforms.md` §5 obs. 2, CONFLICT C-1).

**Explicit non-decision [GAP].** No beachhead category, city, model, or expansion sequence is selected here. Selection belongs to P3, after the three-round council defined in `02_COUNCIL/COUNCIL_PROTOCOL.md`.

**Evidence confidence [E].** The corpus holds: a formal-accessible-channel operator map of Poland (B1, partial by design), two content-bearing global comparator slices (B2-A, B2-C), one comparator slice with zero yield (B2-B), a narrow trust-mechanics slice (B3-A), and an initial visual pass (B6). No legal (B4), no economic/demand (B5), and no demand-side evidence of any kind exists (`00_ADMIN/NOW.md`). Confidence in the supply-side model map: moderate. Confidence in anything about customers, prices, or law: none.

## 2. Research signal ledger

| Bundle | Establishes [E] | Cannot establish |
|---|---|---|
| B1 — `01_RESEARCH/evidence/B1-poland-direct-platforms.md` | 11 Polish operators/channels mapped (marketplaces, classifieds, agencies); Sitly's full two-sided pricing (99.99 zł/mo parents, 19.99 zł/mo carers); N jak Niania's fee as 60% of gross minimum wage; opposite trust postures coexisting (Sitly disclaims checks; Babysits claims mandatory ID verification); agency guarantee convergence on 3 months; Mazovia concentration (72/223 OLX listings); multi-category attempts from two directions (Pomocni.pl sibling sites; BIGMAMA single app) | Market size, share, or ranking; informal channels (Facebook groups, word of mouth) — zero sources collected; demand-side behaviour; pricing for 5 of 11 operators; anything about `sprawdzonaopiekunka.pl` (DNS failure, row B1-14) |
| B2-A — `01_RESEARCH/evidence/B2-A-global-marketplaces.md` | Care.com and Babysits are both family-paid subscription marketplaces whose paywall gates *initiating* contact; they diverge on category breadth (six verticals vs childcare only) and payment posture (Care.com disclaims payment liability; Babysits runs escrow, 24h delayed release, no-show refund, 3%/15% member-protection fee) | Care.com plan tiers (terms truncated at 20k chars); either operator's Poland behaviour; any verified scale figure |
| B2-B — `01_RESEARCH/evidence/B2-B-global-marketplaces.md` | Fetch outcomes only: Rover and UrbanSitter anti-bot 403s, Yoopies routing anomaly (GitHub Pages 404s) | Anything about Yoopies, Rover, UrbanSitter — 0 of 12 taxonomy fields captured; all three UNCLASSIFIED |
| B2-C — `01_RESEARCH/evidence/B2-C-managed-and-specialists.md` | A three-way matching axis: family matches (Sittercity), platform matches (Papa), local office matches (Home Instead); Papa's benefit-funded route (Medicare Advantage/Medicaid/employer) beside direct pay; Honor and Home Instead are one corporate group, stated by both sides (F6); zero monetary amounts across twelve captures (F7) | Any price, take rate, or unit economics; Honor's revenue mechanism; workforce employment status for all four |
| B3-A — `01_RESEARCH/evidence/B3-A-trust-mechanics-marketplaces.md` | No captured platform documents a background check: Sitly disclaims them, Babysits shifts screening to members (terms are a "Mediation Agreement", liability capped at €2,000, Rotterdam forum), Niania.pl uses labels without mechanism; two of three dedicated safety URLs return 404 | Reference/review mechanics behind any label; Niania.pl and Sitly terms/policies; effectiveness or legality of any mechanism |
| B6 — `01_RESEARCH/evidence/B6-initial-visual-scan.md` | Niania.pl: sparse role-selector conversion, SEO city architecture, sibling-site family rather than blended multi-care UX; Babysits: search-first hero with safety block pre-signup; Care.com: six-category "one membership" framing | Screenshot files (capture still open); any post-login experience; Rover and Papa visuals (blocked/timed out) |

## 3. Opportunity architecture

**Categories.**
- **Childcare [E-rich].** The only category with a mapped Polish formal supply side: localised international marketplaces (Sitly, Babysits), an incumbent group (Niania.pl/Pomocni.pl), app products (BIGMAMA, SOS Niania), five agencies, and a classifieds channel that is mostly institutional rather than household (B1 §5 obs. 7).
- **Elder care [GAP-heavy].** Polish evidence is limited to Pomocni.pl's "Opieka seniora" sibling link and BIGMAMA's category list; the global comparators (Papa, Honor/Home Instead) are managed or benefit-funded models whose economics the corpus cannot price (B2-C F7).
- **Pet care [GAP-heavy].** No dedicated Polish operator captured; carried abroad as a marketplace category by Care.com and Sittercity; Rover uncaptured (B2-B).
- **Cross-category [E, existence only].** Attempted in Poland top-down (Pomocni.pl sibling sites), bottom-up (BIGMAMA one app), and as a household bundle (Warsaw Nanny: nanny + home help + pets). Whether any of it works is unknowable from the corpus (B1 §5 obs. 6).

**Comparable operating models [E].** The charter's six-slot taxonomy is fully instantiated by captures: directory (Care.com business listings), self-service marketplace (Sittercity, Sitly, Babysits, Niania.pl), managed matching (Papa; Home Instead's consultative funnel), subscription-on-outbound-contact (Sitly, Babysits, Care.com), staffing/franchise (Home Instead; Care.com's Backup Care carve-out), care-benefit (Papa primary; Sittercity's Bright Horizons side door; "Babysits for Work" named but uncharacterised).

**Evaluation criteria for P3 [H]:** supply recruitability; demand frequency and urgency; trust burden vs deliverable verification; legal surface (B4); monetisation mechanisms observed in-market; incumbent density; adjacency value toward the next category.

**Anti-goals [E].** Premature convergence on childcare because it is the seed (D-005); a generic low-trust listings site (charter); cloning protected brand/UI (charter); and marketing labels that outrun mechanisms — the exact pathology B1 and B3-A document.

## 4. Candidate beachhead scorecard — template only

To be scored during/after council. **UNKNOWN cells must not be scored as facts, and no winner is selected here.**

| Criterion | Childcare PL | Elder care PL | Pet care PL | Cross-category |
|---|---|---|---|---|
| Formal supply mapped | Yes (B1) | Sibling links only [GAP] | None [GAP] | Existence only [E] |
| Demand signal | 223 OLX listings, one snapshot | UNKNOWN | UNKNOWN | UNKNOWN |
| Willingness-to-pay observed | Supply-side price points only (Sitly, agencies) | UNKNOWN | UNKNOWN | UNKNOWN |
| Trust burden | High; verification vacuum documented | UNKNOWN, plausibly higher [H] | UNKNOWN, plausibly lower [H] | Compound |
| Legal surface | B4 open: umowa uaktywniająca, KRAZ, record-check access | B4 open | B4 open | B4 open |
| Incumbent density | Highest observed | UNKNOWN | UNKNOWN | Pomocni.pl group present |
| Adjacency value | → elder/pet per charter | ← child | ← child | n/a |

Scoring rule [H]: a cell may be scored only when it can cite an artifact path; every UNKNOWN routes to the council agenda (§10) or a research bundle (B4/B5).

## 5. Trust operating-system blueprint

Grounding [E]: in the captured market, trust language is decoupled from trust mechanics (B1 C-1; B3-A cross-platform finding: no documented background check anywhere). Core bet [H]: every trust claim carries inspectable provenance — the differentiator is honesty about what was verified, when, and by whom.

| Component | Owner | Evidence/provenance model | Status |
|---|---|---|---|
| Identity verification | Platform | Verification event: method, date, document class — never the document itself | [H]; storage legality → B4 |
| Reference checks | Platform-assisted | Referee contacted, date, outcome logged | [H]; Polish agencies sell exactly this labour today (B1 §4) |
| Criminal-record / eligibility check | Unresolved | Who may lawfully request or see such data in Poland | **[GAP] — must be legally validated (B4) before any claim, storage, or marketing** |
| Reviews/ratings | Users, platform-moderated | Post-interaction only | [H]; Babysits claims post-booking ratings, mechanics unvalidated |
| Messaging and contact shielding | Platform | In-platform contact; PII withheld | [E] pattern: Sitly, Care.com |
| Payments as trust instrument | Platform, later phase | Escrow, delayed release, no-show refund | [E] pattern: Babysits global (B2-A §3.5); excluded now — charter forbids live payment this phase |
| Manual review and complaints | Platform humans | Logged queue with response expectations | [E] pattern: Sitly manual-checks claim; Babysits complaint mediation |
| Insurance, disputes, emergency escalation | Unresolved | — | [GAP] → B3-B, B4, council |

**Marketing label vs real verification [E].** "Sprawdzona/verified" appears on surfaces whose operators disclaim checks (Sitly) or document none (Niania.pl, SOS Niania). Product rule that follows [H]: no badge without a linked verification event; absence is displayed as absence, never softened. **Legal validation required before build (all [GAP], B4):** record-check access and processing; umowa uaktywniająca mechanics; whether a matching platform triggers KRAZ employment-agency registration; DSA obligations (Niania.pl already links DSA); GDPR basis for verification data. This blueprint offers no legal position.

## 6. Candidate MVP concept — HYPOTHESIS ONLY

**Nothing below exists.** The live `baby.nurt.cloud` is a verified read-only research cockpit with no booking, payment, verification, or data collection (`00_ADMIN/NOW.md`).

**Hypothesis flow [H]:** single-city, single-category (both chosen in P3) profile-and-match surface. A family posts a need; carers hold profiles where every trust marker links to a provenance record; matching is family-driven (the Sittercity/Sitly pattern); contact stays in-platform; a human admin reviews verifications and flags. No payments, no booking, no guarantees.

**Prioritised stories [H]:**
1. Carer creates a profile; every verifiable attribute starts as "unverified".
2. Admin performs identity/reference verification → event recorded → badge appears with date and method.
3. Parent posts a need; carers respond; conversation stays in-platform.
4. Parent reports a concern; admin triages a logged queue.
5. Public "how verification works" page stating exactly what is and is not checked.

**Non-goals [H]:** payments/escrow, record-check claims (until B4), elder personal/medical care, multi-city, native apps, algorithmic matching, agency/employer channels.

**Trust/safety boundaries [E+H]:** no live user data during the research phase (charter); no availability or safety guarantees; no medical/legal/insurance claims; unverified status always visible.

**Build vs not-build [H]:**

| Build v1 | Defer | Not this phase |
|---|---|---|
| Profiles + provenance ledger | Escrow payments (Babysits pattern) | Any "verified" badge without a mechanism |
| Family-driven matching + messaging | Reviews (need real interactions first) | Record-check processing before B4 |
| Admin verification queue | Booking/calendar | Guarantee or insurance claims |
| Verification-disclosure page | Agency/employer channels | Cloned protected UI/content |

## 7. Technical architecture proposal — all [H] unless sourced

**Stack [H]:** a boring server-rendered monolith (Django/Rails-class), PostgreSQL, minimal JavaScript, one small-host deployment behind the already-verified proxy/TLS path (`00_ADMIN/TASKS.md` P5-TLS; `reports/evidence/domain-recovery-2026-07-30.md`). No microservices, no queues, no native app until liquidity argues for them.

**Data-model boundaries [H]:** `accounts` (auth only) · `profiles` (public claims) · `verification_events` (append-only ledger: attribute, method, actor, date, outcome — the only source of truth for any badge) · `needs` · `conversations` · `flags`. PII minimised and segregated; verification documents never stored, only event metadata, pending B4.

**Roles [H]:** guest (browse per policy), parent, carer, admin. Admin-only surfaces: verification queue, flag triage, audit log.

**Admin workflow [H]:** every verification and complaint is a queue item with state, assignee, and timestamped decision — the labour Polish agencies charge placement fees for today (B1 §4).

**Telemetry/analytics principles [H]:** consented, minimal event funnel (signup → profile complete → verified → contact → response); one source of truth for counts; no third-party trackers during research/pilot (the current site has none, and the charter forbids adding collection this phase).

**Security/privacy posture [H]:** GDPR-first: data minimisation, erasure path, role-scoped access, TLS enforced, lawful basis for verification data settled in B4 before implementation.

**Implementation sequencing [H]:** (1) skeleton + auth + profiles; (2) provenance ledger + admin queue; (3) needs + messaging; (4) flags + disclosure page; (5) pilot instrumentation. Each step passes local verification and the deployment gates (`05_PROTOTYPE/DEPLOYMENT_GATES.md`) before any deploy.

## 8. GTM and marketing — hypotheses to test, not a plan to execute

**Acquisition hypotheses [H]:** supply-first in one city. Mazovia is the only demand concentration the corpus shows (B1: 72/223 OLX listings; Sitly's Warsaw counts roughly double the next city on both sides), but city choice is a P3 decision. Keep the carer side free — every captured operator that states a policy subsidises supply (B1 §5 obs. 10).

**Supply/demand bootstrapping [H]:** manual matchmaking behind the product until liquidity exists; the corpus shows agencies profitably monetise precisely the trust labour that platforms skip.

**Partner categories [H, no contact this phase per charter]:** first-aid trainers (Niania na medal sells such courses); agencies as customers, not only rivals (Niania.pl operates a "Dla firm i agencji" channel); employers (Babysits for Business, Care for business, the Sittercity–Bright Horizons pattern); institutions/nurseries (the OLX channel is institutionally dominated).

**Positioning angles [H]:** "verification you can inspect" against the documented label inflation; honest local liquidity display instead of "millions" claims (B6 design question 3).

**Pilot design [H]:** one city, one category, bounded cohort, human-reviewed verification, fully measured funnel; thresholds defined before start (§9).

**Channel experiments — what must be tested first [GAP]:** where Polish families actually search (informal channels are B1's largest hole); whether demand pays anything (only supply-side prices are observed); whether carers complete real verification steps. **No conversion or market-size figure exists in the project; none is invented here.**

**Launch assets [H], drafted only after P3:** verification-disclosure page, city landing page, carer onboarding guide, incident-response policy.

## 9. Operating plan

**Team/human review [H]:** minimum viable operation is product/engineering plus a named human verification-and-safety reviewer from day one — verification is labour, not a badge. Control-plane cadence stays in `00_ADMIN/` per D-002.

**Key risks [H]:** (1) a trust incident involving a "verified" carer — mitigated by narrow claims and inspectable provenance; (2) supply cold-start; (3) B4 invalidating a planned check — verification tiers must degrade gracefully; (4) incumbent response (the Pomocni.pl group already spans four care categories); (5) childcare-seed bias hardening without council scrutiny (D-005); (6) research gaps ossifying into assumed facts — the tagging discipline here exists to prevent that.

**Metrics tree [H]:** supply (activated carers, verification coverage) → liquidity (response rate and time per need) → matches (mutual contact) → retention (repeat needs) → trust health (flag rate, complaint resolution time).

**Go/no-go thresholds [GAP by design]:** expressed as measured targets to be set at pilot design from real baselines — e.g. "share of needs receiving ≥N responses within T days", "verification completion rate", "no unresolved safety flag older than Z days". No numbers are invented pre-pilot.

**Experiment cadence [H]:** weekly review during pilot; each experiment logged with hypothesis, measure, and decision; decisions appended to `00_ADMIN/DECISIONS.md`.

## 10. Council agenda (P2, per `02_COUNCIL/COUNCIL_PROTOCOL.md`)

**Round 1 — independent proposals:** beachhead category and geography; expansion sequence child/elder/pet; trust-model stance (self-service + provenance vs managed/agency hybrid vs payment-backed); monetisation hypothesis — subscription, placement fee, and escrow fee are all observed in-market (B1 §5 obs. 5, B2-A).
**Round 2 — adversarial critique:** attack the childcare-seed bias; attack marketplace-vs-managed using the B2-C matching axis; attack trust-OS feasibility absent B4; attack any [H] above that survived unexamined.
**Round 3 — finals, aggregate, dissent:** what evidence would flip each ranking; disagreement register must be non-empty.
**Follow-up research required regardless of outcome [GAP]:** B3-B (≤6 policy URLs per `00_ADMIN/NOW.md`); B4 legal bundle (blocks the entire trust OS); B5 demand/economics (also resolves the minimum-wage conflict C-2 that prices N jak Niania); characterisation of `sprawdzonaopiekunka.pl` (B1 open question 1); informal-channel evidence; app-store third-party scale signals; Pomocni.pl sibling capture; a deterministic compact extract before any B2-S merge retry (D-013…D-015).

## 11. Phased roadmap

| Phase | Work | Concrete artifacts | Exit criteria |
|---|---|---|---|
| P1 evidence (current) | B3-B, B4, B5, B6 screenshots; register completion | evidence files + `01_RESEARCH/evidence/SOURCE_REGISTER.md` rows | every bundle closed or explicitly bounded |
| P2 council | 3 rounds × 3 seats | round folders: proposals, critiques, finals, `AGGREGATE.md`, `DISAGREEMENT_REGISTER.md` | all papers frozen; disagreement register non-empty |
| P3 selection | `[F]` beachhead sign-off addressing each register entry | `03_STRATEGY/` recommendation + scored scorecard (§4) | one beachhead; alternatives' losses explained |
| P4 MVP blueprint | product brief, journeys, trust model, tech plan, measurement plan | `04_PRODUCT/` set; pilot thresholds defined | sponsor accepts scope and non-goals |
| P5 build | original prototype + runbook | `05_PROTOTYPE/` source, screenshots, gate evidence | local verification + deployment gates green |
| P6 pilot | bounded pilot per §8–§9 | pilot report in `06_DELIVERY/` | P4-defined go/no-go thresholds evaluated honestly |

## 12. Appendix — source inventory and limitations

**Sources (all read in full):** `PROJECT_CHARTER.md` · `00_ADMIN/NOW.md` · `00_ADMIN/TASKS.md` · `00_ADMIN/DECISIONS.md` · `01_RESEARCH/evidence/B1-poland-direct-platforms.md` · `01_RESEARCH/evidence/B2-A-global-marketplaces.md` · `01_RESEARCH/evidence/B2-B-global-marketplaces.md` · `01_RESEARCH/evidence/B2-C-managed-and-specialists.md` · `01_RESEARCH/evidence/B3-A-trust-mechanics-marketplaces.md` · `01_RESEARCH/evidence/B6-initial-visual-scan.md` · `02_COUNCIL/COUNCIL_PROTOCOL.md`. Raw corpora live under `reports/evidence/`; the citation register is `01_RESEARCH/evidence/SOURCE_REGISTER.md`.

**Technical/research limitations:** every scale and trust statement in the corpus is operator self-marketing, captured once, from one vantage point; nothing behind registration walls was seen. B2-B yielded zero comparator facts (Rover/UrbanSitter edge-blocked; Yoopies routing anomaly). Care.com's terms are truncated at 20,000 characters; the Babysits "global" home is locale-personalised to Malaysia. All twelve B2-C captures contain no monetary amount. The B2-S aggregate is on technical hold after three Opus timeouts (D-013…D-015). B4 and B5 have not started — no legal or economic fact exists in-project. There is no demand-side or informal-channel evidence. `sprawdzonaopiekunka.pl` is unreachable from this host (B1-14). The Flash/OpenCode-Zen collection lane is unavailable (`00_ADMIN/TASKS.md` P1-0), and box concurrency caps bound future fan-out.

## Self-check — what this blueprint deliberately does not decide yet

No beachhead category, geography, or expansion sequence (P3). No trust component that touches criminal-record or identity-document processing (blocked on B4). No price, fee level, market size, or conversion assumption (B5 + pilot baselines). No launch decision or date. No legal position of any kind. No claim that any MVP feature exists today. Every [H] above is an input for the council to attack, not a plan to execute.