←~/progetti/outpaced/README.md

Outpaced

{ “Datum”: “2026-05-03”, “Status”: “in Entwicklung”, “Stack_Module”: 7 }

Reibungsloses Dependency-Monitoring für JavaScript- und TypeScript-Projekte

Outpaced ist ein öffentliches SaaS, das sofortige Sichtbarkeit über den Zustand von npm-Abhängigkeiten bietet: package.json einfügen und innerhalb von Sekunden ein vollständiges Dashboard zu Updates, CVE-Schwachstellen, veralteten und verlassenen Paketen erhalten. Kein Repo-Zugriff, keine Konfiguration, keine automatischen Pull Requests.

Das Leitprinzip des Produkts: vom Sign-up zum Mehrwert in unter zwei Minuten. Ein zentralisierter Kontrollpunkt für alle, die mehrere Projekte parallel verwalten und auf einen Blick wissen wollen, wie viele kritische Abhängigkeiten sie haben, welche Projekte am stärksten gefährdet sind und was zuerst aktualisiert werden muss.

## Das Problem

Dependency-Monitoring wird heute von zwei Tool-Kategorien dominiert, beide mit klaren Einschränkungen für reine Sichtbarkeit:

·Pull-Request-Bots (Dependabot, Renovate): benötigen Repo-Zugriff, projektweise YAML-Konfiguration und produzieren PRs statt eines aggregierten Dashboards

·Enterprise-Sicherheitsscanner (Snyk, Socket.dev, OWASP Dependency-Track): mächtig, aber für Teams mit Compliance-, SBOM- und Reachability-Anforderungen konzipiert

Die Lücke: Niemand bietet den Flow "package.json einfügen → Dashboard sehen". Outpaced positioniert sich als ergänzendes Werkzeug mit Fokus auf Monitoring und Sichtbarkeit, nicht Automatisierung.

## Die Lösung

Ein bewusst linearer User-Flow:

·Sign-up mit E-Mail und Passwort

·Projekt erstellen, kein Wizard, direkter Einstieg

·package.json einfügen und optional die Lock-Datei für präzise CVE-Analyse

·Asynchrone Analyse im Hintergrund

·Dashboard mit Status jedes Pakets: aktuelle Version, neueste verfügbare, Update-Typ, CVE, Deprecations, Verlassenheit

·Manueller Re-Check bis zu 3 Mal pro Tag plus automatischer nächtlicher Check

·E-Mail-Benachrichtigungen bei neuen kritischen Alerts

## Alert-Typen

Vier verschiedene Signal-Kategorien:

·Outdated — Update verfügbar, Severity von info (Patch) bis critical (Major)

·Deprecated — Paket auf npm als veraltet markiert

·Vulnerability — CVE aus npm Audit und OSV mit CVSS-basierter Severity

·Abandoned — über 2 Jahre ohne Release kombiniert mit Download-Rückgang; das doppelte Kriterium vermeidet Falschalarme bei reifen, stabilen Paketen

## Tech-Stack

Die technischen Entscheidungen spiegeln die Produktanforderungen wider:

·Frontend: SvelteKit, TypeScript und Tailwind CSS, SSR für öffentliche Seiten, SPA für das Dashboard

·Backend: Go mit stdlib und REST API, idiomatische Concurrency mit Goroutines und Channels

·Datenbank: PostgreSQL mit strukturierten Relationen und JSONB, verschlüsselt im Ruhezustand

·Queue und Cache: Redis + Asynq, getrennte Queues für Analyse und E-Mail, Registry-Caching und Rate Limiting

·Auth: Better Auth mit Sessions und JWT, vorbereitet für künftiges Social Login

·Transaktionale E-Mails über Resend oder Postmark

·Datenquellen: npm Registry, npm Audit und OSV (Google) für Metadaten, CVEs und künftige Multi-Ecosystem-Erweiterung

## Zwei-Binary-Architektur

HTTP-Server und Worker sind zwei separate Binaries, die dasselbe Go-Domain-Paket teilen: gleicher Code, unabhängiges Deployment und Scaling, bessere operative Resilienz. Ein Worker-Crash legt die API nicht lahm.

## Wichtige Design-Entscheidungen

Fünf Entscheidungen, die das Produkt prägen:

·Client-seitiges Parsing für Privacy by Design: package.json und Lock-Datei werden im Browser geparst, nur die normalisierte Struktur erreicht den Server

·Verschlüsselung im Ruhezustand pro Workspace: JSONB auf Spaltenebene mit eigenem Schlüssel pro Workspace verschlüsselt

·Rate Limit als Produktentscheidung: 3 manuelle Checks pro Tag schützen die Infrastruktur und respektieren öffentliche npm-APIs

·Expliziter API-Vertrag statt geteilter Typen: OpenAPI als Single Source of Truth zwischen TypeScript und Go

·GDPR-first: Account-Löschung bedeutet sofortige und irreversible Entfernung, keine Aufbewahrungsfrist

## Roadmap

Drei progressive Wertphasen:

·V1 — MVP "manifest paste": Auth, Projects, package.json einfügen, asynchrone Analyse, globales Alert-Center, Rate Limit mit UI-Feedback, E-Mail-Benachrichtigungen, nächtliche Checks, Status-Badge für README

·V2 — Git-Integration: OAuth GitHub, GitLab und Bitbucket, Push-Webhooks, Monorepo-Support, Multi-User-Workspaces

·V3 — Ecosystem-Erweiterung und Monetarisierung: requirements.txt, go.mod, Gemfile, In-Product-Fix-Vorschläge und PRs, Paid Tiers via Stripe, Slack-Benachrichtigungen und Custom Webhooks

## Was ich lerne

Operative Erkenntnisse aus rigorosem Product Scoping:

·Nein sagen zu "offensichtlichen" Features (automatische PRs, Repo-Integration in V1), um die Time-to-Value zu schützen

·Klare Grenzen zwischen Server und Worker vom ersten Tag an entwerfen

·Privacy als Design-Constraint und nicht als Checkbox: Client-seitiges Parsing hat UX-, API- und Größenlimit-Entscheidungen geleitet

·Klare V1/V2/V3-Roadmap, um nichts zu bauen, was gerade niemand braucht

Outpaced ist ein europäisches Produkt mit Sitz in Italien, derzeit in Entwicklung. Stay ahead of your dependencies.

// Stack

[“sveltekit”, “go”, “postgres”, “redis”, “saas”, “devtools”, “dependency-monitoring”, ]