SkyCop Business is a new service on the clean stack. The legacy Partner Platform is a reference design (proven requirements), not code to extend — strangler-fig says don't grow the monolith we're retiring, and a brand-new product with no existing users has nothing forcing it there. One bounded legacy seam only: where a submitted claim lands. No time estimates by design.
The decision: code quality isn't the deciding factor — strategy is. The summer plan retires the monolith; this is a new product with zero migration gravity. So we build fresh on the clean stack and treat the legacy Partner Platform as a de-risked requirements document: it tells us what the business actually needs because it's been running. We extract the model, throw away the PHP.
Honest consequence: the estimate is higher than a "mostly reuse" reading. There is no large free-reuse bucket — only (a) three epics whose requirements are already proven, and (b) integrations into services that already exist.
| Surface | Role | Treatment |
|---|---|---|
Legacy Partner Platformskycop-core/PartnerPlatform | Company/User/Project, agreements, commission, onboarding lifecycle | Reference design only. Re-implement clean; reuse requirements, not PHP. No new code in the monolith. |
| Existing scoring model | "is this disruption worth pursuing" | Integration — wrap behind an API, call it. |
| Flight data in ES (OAG/MeshData) | cancel / 3h+ status | Integration — read. |
| Summer Claim Form CRM-10 + Lead API | pre-fillable form, jurisdiction/eligibility/docs | Integration target — passenger hand-off lands here, not the legacy form. Cross-team dependency. |
| Summer Communication Engine / Email Templates | multi-language outbound | Integration — agent/unassigned/passenger emails. |
| Claim lifecycle (legacy → Validation Engine) | submitted claim continues to pay/reject/pre-legal | The one bounded seam — emitted event + single adapter. |
| Dictionary Service (summer) | airports / airlines / jurisdictions | Integration — derive fields in ingestion. |
New service scaffold (FastAPI + React from new-service/new-frontend), DOKS namespace, CI/CD, observability, identity/auth (agency Owner/Admin/Agent + internal admin), core persistence + base data model, secrets.
PII-free intake (daily XLSX → normalized records), validate/normalize/dedup/idempotent, connecting-flight grouping, agency mappings, PII-free import logs.
Lead importer pattern. Integration: Dictionary Service. Dep: E0, BPC format (Q2/Q3).OAG cancel/3h+ check + call existing scoring model via API → claimable → create Flight lead. Non-claimable = no side effects.
Kanban (no drag-drop), Flight-lead + Claim cards & event-driven stages, create-claim-from-lead, assignment/reassignment, notes, recovery, non-enumerable access.
Agency entity, Owner/Admin/Agent roles, 7-day invites, promote, suspend with active-work guard, agreements/onboarding lifecycle, no hard-delete.
Pre-filled draft, secure non-enumerable link, single-page flow, signature = consent + exclusivity, submission event back, unsigned-PII retention + hard delete. Claim-landing = the one bounded legacy/Validation-Engine contact.
Per-passenger accrual, total-vs-agent split, monthly payout batch (Draft→Reviewed→Exported→Paid), export, mark-as-paid + locking.
Agent assignment email, Unassigned alert to Owner/Admin, passenger templated email with form link.
Agency creation + reward config, lifecycle tracking (Trust→Signing→Implementation→Active→Ended), payout review/export/mark-paid, code-provisioned internal users (v1), self-filter.
Agent (reward-centric), Agency (discipline/conversion), Admin (partner performance). Read-models over CRM data.
DPA/consent/assignment/exclusivity sign-off (legal, gates go-live); unsigned-PII retention + non-recoverable delete; audit trail; ID-based access.
Takeaway for sizing: a real new service — foundation + 3 net-new builds + 3 model-guided rebuilds + 3 integrations + 1 compliance gate. The only relief vs pure green-field: three epics with proven requirements, and three integrations into existing services. No "mostly reuse" discount.
Entire PRD except the scoring model, ~2 months, AI-assisted. Full feature scope — Kanban, roles/invites/suspend, payout lifecycle, admin app, dashboards all in. No trim.
| Epic | Scope (full) | Est |
|---|---|---|
| E0 | foundation (scaffold, auth, data model, CI) | 0.5 wk |
| E1 | flight-feed ingestion | 0.75 wk |
| E2 | disruption → lead (Lead API filter, no scorer) | 0.5 wk |
| E3 | Business CRM — full Kanban, lead→claim, assignment, recovery | 1.5 wks |
| E4 | accounts — roles, invites, suspend | 1 wk |
| E5 | claim-form hand-off + passenger submission | 1 wk |
| E6 | rewards + payout — batch lifecycle, export, mark-paid | 1 wk |
| E7 | notifications | 0.5 wk |
| E8 | admin app | 1 wk |
| E9 | dashboards | 0.75 wk |
| E10 | GDPR / retention / audit (eng) | 0.5 wk |
| Total | full PRD minus scoring | ≈ 9 wks ≈ 2 months |
The one thing AI velocity doesn't shrink: E5 is gated on the summer claim-form (pre-fill + link + submission event) — a cross-team wall-clock dependency, not coding time. Confirm it lands in the window or E5 slips regardless of dev speed. Legal sign-off (E10 non-eng) runs in parallel.
flowchart LR
subgraph P0["Phase 0 · Decisions & contracts"]
D1["BPC/Amadeus feed
format + agent-id"]
D2["Claim-form pre-fill / link /
submission-event contract"]
D3["Legal: retention
window + wording"]
D4["Reward policy +
model guardrail"]
D5["Confirm stack +
claim-landing target"]
end
subgraph P1["Phase 1 · Foundation + spine"]
E0x["E0 Service foundation
(scaffold, infra, auth, data)"]
E1x["E1 Feed ingestion"]
E2x["E2 Disruption + scoring
→ Flight leads"]
end
subgraph P2["Phase 2 · Agent works a lead"]
E3x["E3 Business CRM
(Kanban, lead→claim)"]
E4x["E4 Accounts
(roles/invites/suspend)"]
E7a["E7 agent + unassigned alerts"]
E5a["E5 pre-filled draft + link"]
end
subgraph P3["Phase 3 · Conversion & money"]
E5b["E5 submission event
+ retention/delete"]
E6x["E6 rewards + payout batch"]
E8x["E8 admin app
(onboarding, payout)"]
E7b["E7 passenger email"]
end
subgraph P4["Phase 4 · Visibility & hardening"]
E9x["E9 dashboards"]
E10x["E10 GDPR/audit/access
+ legal sign-off gate"]
end
P0 --> P1 --> P2 --> P3 --> P4
D5 -.gates.-> E0x
D2 -.gates.-> E5a
D1 -.gates.-> E1x
D3 -.gates.-> E10x
style P0 fill:#eef2f9,stroke:#b9c4da
style P1 fill:#eafaf1,stroke:#9fe0bb
style P2 fill:#fff6e7,stroke:#f0cf94
style P3 fill:#feeef0,stroke:#f3b6bd
style P4 fill:#f0ecff,stroke:#c9bdf3
Why this order: P0 nails decisions + the integration contracts before spend ramps (and de-risks the two PRD killers: matching friction, reward-vs-success). P1 stands up the service skeleton (E0) plus the automated spine — provable from logs, no UI; E0 is the front-loaded cost of building from scratch. P2 is the first end-to-end agent value. P3 closes the loop to submission + money. P4 is visibility + the compliance gate before go-live. Each phase holds value if a later one slips.