Incremental Opportunities: Localz (2026-08-20)
Scope: BlogPosts/2026-08-20-sli-slo-observability-pipeline and Architecture/Challenges/design-a-kyc-aml-onboarding-pipeline (both new this window) against two of Localz's own documented gaps.
Finding 1 — the blog post is a live-tested build of the exact stack Localz's own docs already specify, and it directly answers Localz's own flagged "no numeric SLOs" gap
Projects/Localz.md §"Observability Stack" already commits to Prometheus + Grafana as mandatory metrics, plus an OTel Collector described in near-identical language to the blog post's own architecture ("apps emit to metrics endpoint... an OTel Collector acts as the single internal endpoint / 'reverse proxy for observability' that fans out to the right backend"). Separately, the same file flags, twice, that Non-functional-Requirements.md gives only qualitative reliability goals ("high uptime," "quick search") with no numeric SLOs, no p95 latency target, no uptime %, no RTO/RPO — an explicit, named specification gap.
The new blog post isn't just a stack match, it's a working, load-tested instance of the exact plan: FastAPI (Localz's own backend framework) + OTel SDK + OTel Collector + Prometheus + Grafana, with Sloth generating real multi-window burn-rate SLO rules and Alertmanager routing real fired alerts. It supplies the concrete missing piece Localz's own NFR doc doesn't have — a working example of what "define an SLO and get a real burn-rate alert" looks like end to end, plus a documented list of the exact bugs to expect when wiring it (wrong metric names against the Collector's actual export format, coarse histogram buckets skewing histogram_quantile near a latency threshold, a silently-inverted good/bad ratio query, [5m]-window cold-start NaN).
Concrete next step: when Localz's Week 1 observability rollout (Prometheus + Grafana, per the roadmap) actually happens, treat the blog post's repo (fullstackfusions/public_projects/.../sli_slo_observability_pipeline) as the starting Docker Compose scaffold rather than building from scratch, and use its bug list as a pre-flight checklist. This is also the first concrete numeric SLO Localz could adopt as a placeholder default — e.g., borrow the post's own worked example shape (target %, rolling-28-day window, multi-window burn-rate alert) for the booking-critical endpoints (POST /threads/{id}/messages, checkout, booking-lifecycle transitions) that Non-functional-Requirements.md currently leaves unquantified.
Finding 2 — the new KYC/AML design challenge directly matches Localz's provider onboarding flow, which already names KYC as a step with no described pipeline
Projects/Localz.md names "Provider onboarding: account creation → KYC/ID upload → bank/payout setup → profile" as part of the core provider journey, and separately lists Postgres as system-of-record for "bookings, payments, users, KYC, payouts, reviews, disputes, audit trails" — but nowhere in the compiled Localz docs is there a described verification pipeline for that KYC step (vendor selection, decision states, re-screening, audit retention).
Architecture/Challenges/design-a-kyc-aml-onboarding-pipeline (new this window) is a directly-shaped model solution: per-applicant state machine (submitted → verified → screening → decision → {approved, rejected, manual}), fan-out to vendor checks with independent circuit breakers, event-sourced audit ledger as the single source of truth, and — most relevant to a startup handling both GDPR-style deletion requests and AML-style retention requirements simultaneously — crypto-shredding to reconcile "must delete on request" against "must retain for compliance," by encrypting PII under a per-user key and destroying the key rather than editing immutable audit records.
Concrete next step: the next time Localz's provider-onboarding KYC step gets designed in detail (currently just named, not specified), use this challenge's state-machine + crypto-shredding pattern as the starting model rather than a flat "call a KYC vendor API" integration — it's a small platform (not RBC-scale), but the same tension (retain audit trail vs. honor a deletion request) applies at any scale once a provider requests account deletion after KYC has already run.