Non-functional Requirements

Living doc — measurable targets where a target is knowable yet, honest "not yet proven" flags where it isn't. Ties into Stack-Finalization-Draft.md (phases, RTO, data durability) and Localz-Strategy-and-Architecture-Note.md (the trust-engine/scheduler correctness requirements). Revisit whenever a Phase transition happens or real traffic data exists to replace a guess with a number.

Availability & reliability

Phase	Uptime posture	RTO (full VPS loss)	RPO (data loss window)
Phase 1 (10s–100s users)	Best-effort — no formal SLA, solo-run, single VPS	~4 hours, manual (see Stack-Finalization-Draft §Phase definitions)	Up to last successful backup — documented accepted risk, not zero
Phase 2 (1,000s–10,000s users)	Target 99.5%	~15 minutes, semi-automatic	Zero for committed DB writes and in-flight processing — see "Data durability guarantee" in Stack-Finalization-Draft.md, this is a hard requirement not a target
Phase 3 (scaled)	Target 99.9%	Seconds–low minutes, automatic	Zero, carried forward

Performance (targets to instrument, not committed SLAs until real traffic validates them)

• Search results (DB full-text + geo, per Strategy Note §5's "start simple" build order): p95 under 500ms.
• Booking action (create/confirm/cancel), including payment-intent creation: p95 under 1s end-to-end.
• Chat/messaging delivery: under 2s.
• All three instrumented via the already-decided Grafana/Prometheus/OTel stack — a target with no dashboard behind it isn't a real NFR, it's a guess.

Scalability

• Scoped to the Phase definitions table in Stack-Finalization-Draft.md (10s–100s → 1,000s–10,000s → beyond) — scalability work is triggered by hitting a range, not a calendar date.
• Horizontal scalability lives at the stateless app tier only (FastAPI/Next.js), per the architecture already decided — state stays off-box (Postgres/S3) so scaling the app tier doesn't risk data.
• Scheduler/booking correctness (below) must hold at any concurrency level, from the first booking — this is not a scale-driven requirement, it's a correctness one.

Data integrity & durability

• From Phase 2 onward: zero data loss, both data at rest (DB) and data in flight (mid-processing at the moment of a crash) — full mechanism in Stack-Finalization-Draft.md's "Data durability guarantee" section (transactional outbox, idempotent Celery tasks, persisted webhooks, atomic upload commits).
• Phase 1: documented accepted risk — one manual backup + one test restore required before the first outside user (Pre-launch checklist), but no continuous-durability guarantee yet.

Correctness (marketplace-specific — these hold from MVP, they are not scale-gated)

• No double-booking. A slot reservation must be atomic — held briefly (a short-lived hold), then committed or released, never "check then write." See Localz-Strategy-and-Architecture-Note.md §6 and its implementation note for the concrete mechanism. Required from the first booking, not deferred to Phase 2.
• Review trust tiers are derived, never declared. Store the underlying facts (where discovery happened, whether payment was verified, whether completion was confirmed) and compute the tier — never store "verified" as an editable label (Strategy Note §3). This is a correctness/anti-fraud requirement, not a feature nice-to-have.
• Proof of payment can only originate from the Stripe integration — never inferred from an OTP handshake or a user/provider claim (Strategy Note §4). Conflating the two silently breaks the trust model that differentiates Localz from an unverified Facebook review.

Security

• Payments: Stripe Elements/Checkout only — Localz never touches raw card data, minimizing PCI scope to SAQ-A.
• Secure document storage (KYC docs, rental/service agreements): encrypted at rest (S3/R2 default encryption), access scoped per document, not bucket-wide.
• Admin MFA, secrets rotation, and admin-action audit logging are required by the Phase 1 launch gate, not deferred to Phase 2 — cheap to set up, catastrophic if skipped for a solo founder whose own dashboard logins are the company. See Stack-Finalization-Draft.md's "Access, secrets & audit" section.

Privacy & compliance

• Anonymized/proxied communication already designed (Secure-Communication-Design.md).
• ToS, privacy policy, data retention/deletion policy, and marketplace tax handling (1099-K/T4A-style provider reporting) are an open gap — required before the first real (non-founder) user touches production, not a Phase 2 item. Tracked in Stack-Finalization-Draft.md's "Legal & compliance" section.

Observability

• Every core-loop action (search, booking, payment, review) must be traceable end-to-end through the already-decided Grafana/Prometheus/Loki/Sentry/OTel stack — infra-level uptime dashboards alone don't satisfy this; a failed booking must be diagnosable from a trace, not just inferred from an error count.

Usability

• No hard numbers yet — qualitative until real user testing exists:
  • A provider should be able to list a first offering without needing support/documentation.
  • A consumer's search-to-booking path should be the shortest of any local-services flow they've used (the explicit product bet per the Strategy Note — availability-aware, trust-ranked search is the wedge).
• Revisit with real usability-testing numbers once there's a first cohort of real users.

Maintainability & operability (the solo-founder constraint, made explicit)

• Every infra decision must remain operable by one person through Phase 2 — this is why low-ops is priority #4 in Stack-Finalization-Draft.md rather than dropped entirely; HA/security/OSS priorities never get to assume a team that doesn't exist yet.
• Reproducibility: the running infrastructure must be rebuildable from documentation, not from what's in the founder's head. See "Infra-as-code / reproducibility" in Stack-Finalization-Draft.md.