PRD — Product Requirements Document

1. Problem + opportunity

PROSEC Management LTD = enterprise risk management firma (UK + PL ops). Obecnie obsługuje VIP / korporacje / NGO przez high-touch advisory — telefon + email + custom contracts. Brak self-serve booking dla mid-market klientów.

• Opportunity: pomiędzy enterprise (current) a uncoordinated freelance ochroniarzami (rynek dolny) jest pusta nisza — booking platform z weryfikacją + reputacja.
• Analogia: Uber/Bolt dla pojazdów, ale dla ochroniarzy + transport VIP. mPay + ratings + dispatcher = standard marketplace primitives.
• Risks: regulowana branża (koncesja MSWiA), trust mass-market dla VIP services, marketplace cold-start (chicken-and-egg ochroniarze ↔ klienci).

2. Koncesja MSWiA — wymóg prawny PL

Ustawa o ochronie osób i mienia (Dz.U. 1997 nr 114 poz. 740). Każda firma świadcząca ochronę osób w PL musi mieć koncesję MSWiA. Operator platformy (aggregator) — niejednoznaczne, but conservative read: operator też potrzebuje koncesji lub musi działać wyłącznie jako koncesjonowani podwykonawcy.

• Opcja A — PROSEC własna koncesja PL: PROSEC LTD ma polską spółkę-córkę z koncesją (TBD verify). Operator = ta spółka. Wszyscy ochroniarze = subcontractors z własnymi licencjami osobistymi (II stopień + cert MSWiA).
• Opcja B — agregator: PROSEC = software house, każdy ochroniarz w platformie operuje z własnej firmy z koncesją. Klient kontrahuje z firmą ochroniarską, platforma = tylko discovery + booking + payments + ratings. Risk niższy ale UX gorszy.
• Decyzja przed dev: PROSEC musi potwierdzić ścieżkę (A vs B). Lawyer review + insurance coverage included. Wpływa na contract architecture (multi-tenant per firma vs single tenant per ochroniarz).

Action item: Cze + Krystian → discovery call z PROSEC: koncesja PL spółki-córki? Lawyer dostępny? Insurance carrier?

3. Konkurencja w PL — landscape

Quick research — kto jest na rynku booking ochroniarzy w PL (2026):

• Enterprise ochrona (incumbents): G4S Polska, Konsalnet, Securitas, Solid Security. Wszyscy contract-based + sprzedaż relacyjna, brak self-serve apki.
• Event security platforms: kilka mniejszych (Eventseal, Securio) ale tylko dla eventów, brak per-hour booking.
• Generic marketplace (Useme, Booksy): cross-vertical, brak weryfikacji licencji MSWiA + brak insurance compliance.
• Międzynarodowe (Bond, Trustify): focus US/UK, nie PL.

Differentiator PROSEC APP: PL-native + weryfikacja MSWiA + mPay native + enterprise pedigree (PROSEC LTD as anchor). Pierwsza self-serve apka per-hour z pełną regulacyjną zgodnością.

4. mPay merchant + payments architecture

mPay = polski payment processor (BLIK + karty + wallet). Wymaga merchant account z KYC (full firma docs, regulatory checks).

• mPay setup: PROSEC LTD PL spółka aplikuje o merchant. Fee ~1.5-2.5% transaction (negocjowane na wolumen). KYC ~5-10 dni.
• Flow: klient płaci platformie → escrow → po zakończeniu service → split (X% platforma fee, Y% ochroniarz/firma). Ratings unlock payout po confirm.
• Wallet: opcjonalne — klient ładuje balance dla recurring (transfery lotnisko). Reduces friction dla power users.
• Fakap risk: chargeback dla services niewykonanych. Procedure: dispute window 48h post-service + ratings evidence + fotos lokalizacji + GPS log ochroniarza.

5. Marketplace dynamics — cold start + scale

2-side marketplace: ochroniarze (supply) ↔ klienci (demand). Classic chicken-and-egg.

• Supply seeding: PROSEC + Krystian's network — recruitment 50-100 zweryfikowanych ochroniarzy z koncesjami przed launch. Stałe wynagrodzenie pierwsze 3 miesiące dla aktywności (nawet bez zleceń) → utrzymanie pool.
• Demand seeding: PROSEC existing klienci (VIP, korporacje) onboarded do apki jako "convenience layer" do existing contractów. Plus marketing PL (LinkedIn dla B2B, Google Ads dla eventy/transfery).
• Geography: Warszawa first (largest market, PROSEC HQ). Kraków + Wrocław po 6 mies jeśli unit economics OK.
• Pricing: dynamic — base rate per typ usługi + multiplier (weekend, noc, holidays, VIP risk profile). Marketplace fee 15-25% per transaction (industry standard).

6. Tech stack — recommendation

Wybór mobile framework wpływa na cost + speed + UX:

• Flutter (rekomendacja Lee): single codebase iOS+Android, ~80% wspólnego kodu, fast dev (Hot Reload). Cons: ekosystem mniejszy niż RN, web preview ograniczony. Best fit dla MVP z budżetem.
• React Native: większy ekosystem, dev'erzy łatwiej znaleźć (RN > Flutter w PL). Cons: native module bridges, czasem performance issues z mapami.
• Native (Swift + Kotlin): best UX, full platform features. Cons: 2x development time + cost + 2 teamy.
• Backend: Python (FastAPI) + PostgreSQL + Redis. Mesh integration ready (czak v2 platform). CF Workers dla edge endpoints (low-latency dispatch). Stripe-style architecture.
• Maps + GPS: Mapbox (better PL tiles + cost) lub Google Maps. Geo-matching dispatcher dla closest available ochroniarz.

Lee recommendation: Flutter + Python backend + Mapbox + mPay SDK. MVP w 12 tyg dla 1 region. Discovery call confirm tech stack po PROSEC sign-off.

7. GDPR / RODO — sensitive data

Apka ochroniarska zbiera highly sensitive PII:

• Lokalizacje VIP (real-time GPS klientów + ochroniarzy)
• Identyfikacja personelu (licencje MSWiA, zdjęcia, kontakty)
• Historie zleceń (kto kogo chronił, kiedy, gdzie)
• Płatności (mPay tokeny, faktury)

DPIA (Data Protection Impact Assessment) mandatory przed launch. Recommended controls:

• Hosting w UE only (Hetzner DE/FI). Brak US sub-processor dla danych klientów.
• Encryption at rest (DB) + in transit (TLS 1.3). Field-level encryption dla lokalizacji + licencji.
• Retention policy: lokalizacje GPS 30 dni, financials 5 lat (PL tax), profile data do request usunięcia.
• Access logs każda akcja na PII (compliance audit).
• Klient prawa: export, delete, rectify — built-in flows w apce (RODO art. 15-17).

8. MVP scope — co dostarczymy w 12 tyg

• ✅ Mobile apka (Flutter) — klient + ochroniarz osobne flow
• ✅ Backend API (Python/FastAPI + PostgreSQL)
• ✅ Dispatcher (geo-matching, zlecenia, fallback dla pilnych)
• ✅ mPay integration (BLIK + karty, escrow + payout)
• ✅ Ratings 2-way + dispute flow
• ✅ Panel ochroniarza (web + mobile) — status, zlecenia, payouts
• ✅ Panel klienta (web + mobile) — historia, faktury, oceny
• ✅ Roster onboarding flow (licencja MSWiA upload + verify + KYC)
• ✅ Admin panel PROSEC (dispatcher override, monitoring, payouts)
• ✅ DPIA + RODO compliance framework + dokumenty

NIE w MVP (Faza 3+ po launch):

• Multi-region (start: tylko Warszawa)
• Subscription tiers dla klientów (start: pay-per-use)
• Insurance bundle (start: każdy ochroniarz ze swoją + PROSEC umbrella)
• White-label dla innych firm ochrony (post-PMF)

9. Timeline + budget (estymata)

• Tygodnie 1-2: discovery, koncesja audit, lawyer, mPay merchant aplikacja, tech stack final decision
• Tygodnie 3-6: backend core (API, DB, auth, dispatcher), Flutter setup, design system
• Tygodnie 7-10: apka klient + ochroniarz, mPay integration, ratings, admin panel
• Tygodnie 11-12: roster onboarding, beta testing z 10-20 ochroniarzami, fixes, launch readiness

Budget: dyskusja w discovery call. Lee preliminary range: ~120-250k PLN dla MVP (zależy od tech stack + branding intensity + custom integrations). Cze + PROSEC negocjują.

10. Open questions dla PROSEC

1. Koncesja MSWiA — PROSEC LTD PL spółka-córka ma? Lub model aggregator z koncesjonowanymi podwykonawcami?
2. Roster pool — PROSEC ma własnych etatowych ochroniarzy z licencjami? Czy marketplace dla freelancerów?
3. mPay merchant — kto aplikuje (PROSEC LTD lub joint venture z itm8)?
4. Marketing budget post-launch dla cold start?
5. Branding — PROSEC APP czy white-label dla większej skali?
6. White-label monetization (Faza 3) — interest PROSEC w platform-as-service dla innych firm ochrony?