Dein Claude-Code-Output funktioniert — jetzt wird er zur SaaS

Claude Code ist Anthropics agentisches Coding-Tool im Terminal: Es liest deine ganze Codebase, plant Schritte, führt Shell- und Git-Befehle aus, editiert Dateien und integriert MCP-Server, Skills und Subagents. Je nach Modell und Setup kann Claude Code grosse Codebases, komplexe Refactorings und Sprachen jenseits von TypeScript besser bearbeiten als reine Browser-Builder.

Genau dadurch entsteht aber auch das Risiko. Claude Code sagt zu schnell Ja, wenn der Prompt unklar ist, und wählt einen plausiblen Pfad. Auth wird auf Endpoint A korrekt gesetzt und auf dem später hinzugefügten Endpoint B vergessen. Tests bestehen den Lauf, prüfen aber nichts Inhaltliches. Secrets landen im Code, weil das Beispiel im Tutorial es so zeigte.

Das bringen wir in Ordnung. Häufig in vier bis acht Wochen. Mit ehrlicher Einschätzung, klarem Plan und ohne versteckte Kosten.

Stärken und Grenzen

Was Claude Code kann — und wo es endet

Claude Code ist gut darin, in grossen Codebases tief zu arbeiten. Die Stärken:

  • Tiefe Codebase-Erkundung: Je nach Claude-Modell grosser Kontext, agentische Suche statt manuelles Kontext-Sammeln. Gut für Codebases, die reine UI- oder Browser-Builder überfordern.
  • Sprach- und Stack-agnostisch: TypeScript, Python, Go, Rust, Java sind kein Problem. Du wirst nicht in einen Stack gezwungen.
  • Plan Mode und Subagents: Der Agent denkt vor dem Schreiben, kann Aufgaben an spezialisierte Subagents delegieren und das Ergebnis mergen.
  • MCP und Skills: Eigene Tools, Datenbanken und APIs werden über das Model-Context-Protocol angebunden, statt abhängig von einem Hersteller-Ökosystem zu sein.

Wo Claude Code an Grenzen stösst:

  • Ja-Sager bei vagen Prompts: Der Agent fragt zu selten zurück und nimmt eine plausible Annahme. Was du nicht spezifizierst, bleibt Lotterie.
  • Operations-Blindheit: Logging, Monitoring, Rate-Limits, Backups, CI/CD kommen nur, wenn du sie explizit verlangst. In einer Studie über fünf reale Projekte hatten 5 von 5 weder Error-Monitoring noch strukturierte Logs.
  • Test-Theater: Claude Code generiert Tests, die laufen, aber selten Business-Logik prüfen. expect(user).toBeDefined() ist die Norm, nicht die Ausnahme.
  • Auth-Drift über Sessions: Auth-Middleware ist auf den ersten Endpoints sauber, fehlt aber auf später ergänzten. Das sehen wir besonders bei längeren Agent-Sessions ohne klare Projektregeln.
  • Eigene Sicherheitsrisiken: Prompt-Injection über Issues, Tickets oder MCP-Tool-Beschreibungen, unsichere Hooks und MCP-Token-Handling. Öffentlich berichtete Themen wie CVE-2025-59536 und CVE-2026-21852 zeigen, dass Projekt-Konfigurationen ernsthaft geprüft werden müssen.
Die Lücken

Sechs typische Lücken in einem Claude-Code-Output

01
Auth-Drift: Middleware fehlt auf später ergänzten Endpoints

In längeren Claude-Code-Projekten können später ergänzte API-Endpoints ohne Auth-Middleware entstehen, wenn Anforderungen nicht explizit in Projektregeln verankert sind. Folge: Endpoint /admin/users/:id ist authentifiziert, /admin/users/export nicht. Datenabzug ohne Login möglich.

02
Hardcoded Secrets im Source-Code

In Prototypen liegen Stripe-Keys, SendGrid-API-Tokens oder Datenbank-Connection-Strings gelegentlich direkt im Code statt in einem Secret-Store. Claude Code kann Beispiel-Werte aus Tutorials oder MCP-Tool-Antworten übernehmen. Sobald das Repo öffentlich oder breit geteilt wird, sind solche Schlüssel kompromittiert.

03
Tests laufen, prüfen aber nichts

Viele Prototypen haben Tests mit Assertions wie expect(result).toBeDefined() oder expect(response.status).toBe(200), ohne zu prüfen, ob die Bestellung tatsächlich verbucht, der Lagerbestand reduziert oder die Mehrwertsteuer korrekt berechnet wurde. Der Test ist grün, der Bug ist trotzdem live.

04
MCP-Server und Hooks ohne Audit

Claude Code kann MCP-Server und Hooks aus der Projekt-Konfiguration nutzen. Öffentlich berichtete Sicherheitslücken rund um Hooks, Projekt-Konfiguration und Token-Handling zeigen: Solche Integrationen müssen auditiert werden. In Prototypen wird selten geprüft, welche MCP-Server tatsächlich vertrauenswürdig sind.

05
Multi-Tenancy: Tenant-Filter fehlt punktuell

Claude Code generiert die ersten Queries mit Tenant-Filter sauber. Über mehrere Sessions, mehrere Subagents und neue Features driftet das. Eine Aggregation, eine Background-Job-Query, ein Admin-Endpoint vergisst den Filter. Folge: Mandant B sieht in einem Reporting-Endpoint Daten von Mandant A. Datenschutzpanne, schwer zu finden.

06
Kein Logging, kein Monitoring, kein Runbook

Viele Prototypen haben weder strukturiertes Logging noch Error-Monitoring. Try/Catch-Blöcke fangen Fehler ab, schreiben sie aber nirgendwo hin. Wenn etwas in Produktion bricht, erfährst du es aus einer Kundenmeldung, nicht aus deiner Telemetrie. Dazu fehlt oft ein Runbook: was tun bei Stripe-Webhook-Ausfall, bei Datenbank-Lock, bei MCP-Server-Timeout.

So arbeiten wir

In drei Phasen vom Prototyp zur SaaS

01

Code-Analyse

1 bis 2 Wochen, kostenlos
  • Sicherheit: Hardcoded Secrets, Auth-Drift, Input-Validation, SQL-/NoSQL-Injection, IDOR-Risiken in Routen.
  • Architektur: Multi-Tenancy konsistent? Tenant-Filter überall, auch in Background-Jobs und Admin-Routes?
  • MCP- und Hook-Hygiene: Welche MCP-Server sind aktiv, welche Hooks laufen, sind Deny-Rules gesetzt?
  • CLAUDE.md-Audit: Ist die Repo-Konstitution sauber, oder driften neue Sessions in inkonsistente Patterns?
  • Test-Wirksamkeit: Prüfen die Tests Business-Logik oder nur Status-Codes?
  • Operations-Lücken: Logging, Monitoring, Rate-Limits, Backups, CI/CD-Pipeline.
  • Du bekommst eine schriftliche Risiko-Übersicht, einen priorisierten Plan, eine Aufwands- und Kostenschätzung und einen Zeitplan bis zum Live-Gang.
02

Sicher und produktionsreif machen

4 bis 8 Wochen
  • Sicherheit zuerst: Auth-Middleware konsistent auf jeder Route, Secrets aus dem Code in einen Secret-Store (Doppler, Infisical, Cloud-natives Vault), Eingaben mit Zod oder Valibot zur Laufzeit validieren.
  • CLAUDE.md als Repo-Konstitution: Auth-, Tenancy-, Validation-, Logging-Anforderungen festschreiben, damit folgende Claude-Code-Sessions nicht erneut driften.
  • Multi-Tenancy: Tenant-ID auf jeder Zeile, Filter in einem zentralen Repository-Layer erzwungen, RLS-Policies wo Postgres im Spiel ist, Audit-Tests pro Tenant.
  • MCP- und Hook-Hardening: Whitelist statt Implicit-Trust, Deny-Rules für riskante Netzwerk- und Secret-Zugriffe, Sandbox für lokale Claude-Code-Runs wo sinnvoll.
  • Echte Tests: Unit, Integration, End-to-End mit Business-Assertions (Bestellung verbucht, Mehrwertsteuer korrekt, E-Mail im Queue) für die kritischen Pfade.
  • Überblick im Betrieb: strukturierte Logs (pino, winston oder loguru), Error-Monitoring (Sentry oder GlitchTip), Rate-Limits pro IP und pro Nutzer, Health-Checks, Runbooks für die häufigsten Ausfälle.
  • Getrennte Umgebungen, CI/CD-Pipeline, Stripe-Webhooks mit Schweizer Mehrwertsteuer, Dokumentation der Architektur-Entscheidungen als ADRs.
03

Wachsen und mitskalieren

laufend
  • Monitoring deiner Kennzahlen, Alarme bei steigender Fehlerrate oder Latenz.
  • Re-Audit jeder grösseren Claude-Code-Session, bevor sie in den Hauptbranch geht — automatisiert über Pull-Request-Hooks.
  • Aktualisierung der MCP-Server- und Skill-Whitelist bei neuen Releases, Patch-Pflicht bei CVEs.
  • Modell-Routing für Claude-Code-API-Kosten (Opus für Plan, Sonnet für Routine), gemeinsame Roadmap und Feature-Priorisierung.
Heuristik

Wann lohnt sich Härtung, wann Neuaufbau?

Härtung passt, wenn:

  • Dein Claude-Code-Output ist inhaltlich richtig und die Geschäftslogik trägt.
  • Die Architektur-Entscheidungen sind nachvollziehbar (kein Wildwuchs aus drei Subagent-Sessions).
  • Die Datenbankstruktur ist sauber normalisiert, Foreign Keys sind vorhanden, MCP-Server sind dokumentiert.
  • CLAUDE.md existiert oder lässt sich nachträglich pflegen, ohne dass die halbe Codebase widerspricht.

Dauer: 4 bis 6 Wochen.

Neuaufbau ist besser, wenn:

  • Mehrere Subagent-Sessions haben dieselbe Aufgabe widersprüchlich gelöst und die Codebase ist inkonsistent.
  • Die Datenbankstruktur ist grundsätzlich falsch (Single-Table-Design, fehlende Mandanten-Trennung von Anfang an).
  • MCP-Server und Hooks sind ungeprüft eingebunden, Secrets sind weit verstreut, ein Audit-Aufwand übersteigt den Reset.
  • Du brauchst eine Architektur, die der Prototyp nicht abbildet (Event-Sourcing, Echtzeit-Sync, FINMA-konforme Schlüsselhoheit).

Dauer: 8 bis 16 Wochen.

Preisrahmen

Was kostet die Claude-Code-Härtung?

Code-Analyse
Kostenlos

Schriftlicher Bericht, Risiko-Übersicht, Härtungs-Plan inklusive MCP- und Hook-Audit. 1 bis 2 Wochen.

Härtung (Standard)
CHF 10’000 bis 40’000

Für Claude-Code-Output mit klarer Grundstruktur. 4 bis 6 Wochen. Auth-Härtung, Logging, Tests, Multi-Tenancy, MCP-Whitelist.

Härtung (komplex)
CHF 40’000 bis 80’000

Für grössere Claude-Code-Codebases mit eigenen MCP-Servern, vielen Subagents und besonderer Compliance. 6 bis 8 Wochen.

Neuaufbau
CHF 80’000 bis 300’000

Wenn zu viel von Grund auf neu gebaut werden muss. 8 bis 16 Wochen.

Betrieb und Weiterentwicklung
Monatlich skalierbar

Wir managen Infrastruktur, Wartung, Sicherheit, Updates und Skalierung. Du kannst weiter mit Claude Code bauen; wir prüfen, härten und mergen jede Session kontrolliert über klare Regeln und eine saubere Pipeline in den produktiven Betrieb. Die monatlichen Kosten wachsen mit Nutzung und Anspruch.

FAQ

Häufige Fragen zu Claude Code und SaaS

Kann ich meinen Claude-Code-Output auf einen Produktiv-Stack migrieren?

Ja, wenn die Architektur tragfähig ist. Claude Code generiert oft standardnahen Code in TypeScript, Python, Go oder Rust, häufig mit Frameworks wie Next.js, Express, FastAPI oder Hono. Wir prüfen ihn, ergänzen Auth-Middleware konsistent, schreiben Projektregeln so, dass folgende Sessions weniger driften, und sichern Secrets in einem Secret-Store. Der Aufwand hängt vom Zustand der Codebase ab.

Was bleibt von meinem Claude-Code-Output erhalten?

Das hängt stark von Struktur, Tests und Sicherheitsrisiko ab. Geschäftslogik, UI-Komponenten und gut strukturierte Module bleiben oft erhalten. Wir tauschen vor allem operative und sicherheitskritische Schichten: Auth, Validation, Logging, Multi-Tenancy, MCP-Konfiguration. Wenn dein Output über mehrere Agent-Sessions inkonsistent geworden ist, kann ein grösserer Umbau sinnvoller sein.

Welche Tools, MCP-Server und APIs hat Claude Code bei meinem Code üblicherweise verwendet?

Das hängt stark von deinen Prompts und deinem CLAUDE.md ab. Häufig sehen wir: Drizzle oder Prisma als ORM, Postgres oder SQLite als Datenbank, Hono oder Express als Server, Vite oder Next.js im Frontend, Stripe für Bezahlung, Resend oder SendGrid für E-Mail. MCP-Server kommen oft für GitHub, Postgres, Filesystem oder Browser-Automation dazu. Anders als Lovable hat Claude Code keinen Standard-Stack, sondern wählt opportunistisch. Genau das prüfen wir im Audit.

Was ist mit MCP-Servern, Hooks und Subagent-Output?

MCP-Server und Hooks sind sensible Stellen. Öffentlich berichtete Claude-Code-Themen wie CVE-2025-59536 und CVE-2026-21852 zeigen, dass Projekt-Konfiguration, Hooks und Token-Handling ernsthaft geprüft werden müssen. Wir auditen aktive MCP-Server-Quellen, setzen Whitelists, prüfen riskante Shell-/Netzwerkzugriffe und behandeln Agent-Output wie jeden anderen Pull-Request: Review, Tests, dokumentierter Merge.

Wie unterscheidet ihr eine Claude-Code-Codebase von einer Codex-Codebase?

Claude Code nutzt Markdown-basierte Subagents, Skills, Hooks und das Verzeichnis .claude/ mit settings.json und CLAUDE.md. Codex CLI verwendet TOML-Profile, AGENTS.md und das Verzeichnis .agents/. Beide laufen agentisch, aber das Tooling, die Sandbox-Strategie und die OAuth-Bindung unterscheiden sich. Im Audit prüfen wir entsprechend andere Stellen. Wenn du beide Tools parallel nutzt, dokumentieren wir die Verantwortungs-Grenzen in einer einzigen Repo-Konstitution, damit kein Tool dem anderen ins Werk pfuscht.

Wie lange unterstützt ihr mich nach dem Launch?

Wir sind von Anfang an für dich da. Uns ist wichtig, dass ihr mit eurer SaaS-Lösung langfristig erfolgreich seid, weil beide Seiten davon profitieren: du bekommst ein stabiles Produkt, wir gewinnen eine starke langfristige Partnerschaft. Deshalb ist uns der laufende Betrieb besonders wichtig. Unsere Begleitung ist optional, sorgt aber dafür, dass Infrastruktur, Wartung, Sicherheit, Updates und Skalierung mitwachsen. Speziell bei Claude Code: wir auditen jede grössere Session über Pull-Request-Hooks, bevor sie in den Hauptbranch geht. Ohne diese Begleitung kann eine einzige unbedachte Session monatelange Härtungsarbeit aushebeln.

Können wir mit zweiwöchigen Etappen arbeiten?

Ja, das ist unser Standard. Alle zwei Wochen Code-Review und Demo der letzten Features, danach die nächste Etappe. Du kannst jederzeit Prioritäten verschieben. Bei Claude-Code-Projekten arbeiten wir zusätzlich mit einer geprüften Plan-Mode-Pipeline: Du legst den Auftrag in Plan Mode an, wir reviewen den Plan vor der Ausführung und mergen das Ergebnis erst nach automatisierten Sicherheits- und Test-Checks. Das hält das Tempo hoch und die Codequalität stabil.

Kostet die Code-Analyse wirklich nichts?

Ja. Wir analysieren deinen Claude-Code-Output kostenlos, inklusive MCP- und Hook-Audit, CLAUDE.md-Review und Sicherheits-Scan. Danach sagen wir dir ehrlich, ob sich eine Härtung lohnt oder ob ein Neuaufbau sinnvoller ist. Wenn du nicht mit uns arbeiten möchtest, ist das in Ordnung. Du behältst den Bericht und kannst die Empfehlungen selbst umsetzen.

Bereit, deinen Claude-Code-Prototyp produktionsreif zu machen?

Schick uns dein Git-Repo. Wir auditen es kostenlos, inklusive MCP- und Hook-Konfiguration, und schicken dir einen schriftlichen Bericht und einen klaren Härtungsplan.