Codex Sites vs. Custom Web App: Wann sich was lohnt, 2026

Die Codex Sites vs. Custom Web App-Frage lässt sich klar beantworten: Codex Sites für interne Workspace-Apps, überprüfbare Prototypen und temporäre Tools. Ein Custom Web App dagegen, sobald externe Nutzer, dauerhaft relevante Geschäftsdaten, komplexe Auth-Anforderungen, Compliance, Integrationen oder Source-Code-Ownership das Projekt bestimmen.

OpenAI hat am 2. Juni 2026 keine Web-Agenturen abgelöst. Abgelöst wurde die Ausrede, ein Team brauche einen Monat, um eine erste lauffähige Version zu sehen.

Das ist relevant, wenn eine Idee im Team seit Wochen als Dokument, Tabelle oder Dashboard existiert, für das keine Zeit bleibt. Dieser Artikel liefert die Entscheidungslinie, die Risikoprüfung und den Preisrahmen. Er trennt, was Codex Sites gehört, von dem, was in eine produktionsreife Custom Web Application gehört.

• Codex Sites ist am stärksten für interne Workspace-Apps. Planer, Dashboards, Review-Hubs, Spiele und Einzel-Tools, die das Team hinter kontrolliertem Zugang nutzt.
• Jede Sites-Deployment-URL ist sofort produktiv. Die OpenAI-Dokumentation empfiehlt, eine Version zuerst zu speichern, wenn vor dem Live-Gang ein Review gewünscht wird.
• Custom Web Apps gewinnen, wenn die App das Geschäftsmodell trägt. Externe Nutzer, private Daten, feingranulare Berechtigungen, direkte API-Integrationen und langfristige Ownership verschieben die Arbeit aus Sites heraus.
• Der häufigste Fehler: einen Prototypen zur Plattform erklären. Denselben Fallstrick beschreibt der Beitrag zu Vibe-codierten MVPs als Tech-Debt.
• webvise entwickelt fokussierte Full-Stack-Anwendungen in 4 bis 10 Wochen, wenn die Arbeit Source Code, Architektur, Monitoring und Übergabe statt einer temporären Workspace-App erfordert.

Was Codex Sites tatsächlich liefert

OpenAI hat Codex Sites am 2. Juni 2026 angekündigt, zusammen mit Rollen-Plugins und Annotationen für gemeinsame Reviews. Laut Ankündigung hat Codex inzwischen mehr als 5 Millionen wöchentliche Nutzer, die Nutzung außerhalb von Entwicklerteams ist im Vormonat um den Faktor 3 gewachsen und macht inzwischen über 20 Prozent der Gesamtnutzung aus.

Das Produktversprechen benennt die Zielgruppe präzise. Codex ist kein reines Coding-Interface für Engineers mehr. Es ist ein Workspace-Tool für alle, die einen Plan, eine Tabelle, einen Prozess oder eine grobe Produktidee haben und daraus etwas Interaktives machen wollen.

Die Codex Sites-Dokumentation beschreibt einen gehosteten Workflow, in dem Codex Websites, Web-Apps und Spiele erstellen, speichern, deployen und inspizieren kann. Sites-Projekte können D1 für relationale Daten, R2 für Dateispeicherung, workspace-authentifizierte Identitäten und konfigurierbare Zugriffsmodi nutzen.

Ein entscheidendes Detail geht leicht unter: Jede Sites-Deployment-URL ist sofort produktiv. Wer vor dem Go-live reviewen will, muss laut Dokumentation explizit eine Version speichern, ohne sie zu deployen.

Die Entscheidungslinie: Zielgruppe und Ownership

Die erste Frage ist nicht, ob Codex das Interface bauen kann. Das gelingt oft weit genug. Entscheidend ist, wer auf das Ergebnis angewiesen ist, sobald die URL existiert.

Ist die Zielgruppe das interne Team, der Zugang workspace-beschränkt und ein Fehler nur eine verzögerte Entscheidung, passt Sites gut. Sind Kunden, Partner, Regulatoren oder zahlende Nutzer im Spiel, trägt die Anwendung ein anderes Risikoprofil. Dann braucht sie Architektur, Support-Pfade, Observability und Change Control.

Ownership ist die zweite Linie. Ein temporäres Planungstool kann im gehosteten Workspace leben. Ein Kernprodukt gehört in Source Code unter eigener Kontrolle, mit einer Infrastruktur, die das Team inspizieren, testen und migrieren kann.

Wer dreimal in die rechte Spalte fällt, sollte Sites als Discovery-Tool nutzen, nicht als Produktionspfad. Genau dort setzt webvises Full-Stack-Application-Service an: Next.js, PostgreSQL, Better Auth, tRPC, Drizzle, Deployment, Monitoring und Übergabe als eine eigene Codebase.

Wo Codex Sites klar punktet

Sites überzeugt, wenn die Kosten einer fehlenden Workflow-Visualisierung höher sind als die Kosten einer rohen ersten Version. Das Team kann ein Dashboard, eine Planungs-App, eine Simulation oder einen Review-Hub anfordern und das Ergebnis einer kontrollierten Gruppe zeigen.

Ein realer Beleg aus dem Launch ist die Verschiebung, wer überhaupt starten kann. Am 2. Juni 2026 positionierte OpenAI Codex für jede Rolle, nicht nur für Engineers. Das zählt, weil viele nützliche interne Apps nie als Ticket entstehen. Sie entstehen als Finanzmodell, Launch-Plan oder unstrukturiertes Operations-Sheet.

Der richtige Sites-Auftrag ist eng gefasst: diesen Plan in ein funktionierendes internes Tool verwandeln, das das Team heute durchklicken kann. Der falsche Auftrag ist weit: die Plattform bauen, auf die Kunden in den nächsten drei Jahren angewiesen sein werden.

• Interner Launch-Planner. Eine Launch-Checkliste in ein Status-Board mit Verantwortlichen, Terminen und Blockern umwandeln.
• Forecast-Sandbox. Ein Tabellenmodell in Schieberegler, Tabellen und gespeicherte Szenarien für ein Führungsreview übersetzen.
• Training-Spiel. Eine kleine interaktive Übung für einen internen Workshop bauen, ohne ein vollständiges Produkt zu beauftragen.
• Workflow-Prototyp. Operations-Mitarbeitende den Prozess durchklicken lassen, bevor Felder in einem Spec diskutiert werden.
• Temporäres Dashboard. Einen begrenzten Datensatz für das wöchentliche Meeting in eine Review-Oberfläche ziehen.

Das sind wertvolle Apps. Aber es sind auch begrenzte Apps. In dem Moment, in dem sie zur einzigen Wahrheitsquelle werden, ändert sich die Entscheidung.

Wo Custom Web Apps weiterhin überlegen sind

Custom Web Apps gewinnen, wenn die Software Teil des Betriebsmodells wird. Die Anwendung braucht dann eine nachvollziehbare Auth-Logik, ein teamkontrolliertes Datenmodell, Integrationen die nicht von einem Prompt abhängen, und Error Handling, das außerhalb regulärer Arbeitszeiten läuft.

Bei webvise wird Full-Stack-Anwendungsarbeit um Workflow, Rollen, Datenmodell, Integrationen, Monitoring und Übergabepfad herum gescoped. Fokussierte Produktionsanwendungen laufen typischerweise 4 bis 10 Wochen und enthalten, was eine Prompt-Demo überspringt: Datenbankarchitektur, API-Verträge, rollenbasierte Berechtigungen, CI/CD, Monitoring und einen strukturierten Übergabepfad.

webvise.io ist der interne Nachweis des Modells, ohne auf externe Projektreferenzen angewiesen zu sein. Die Site ist ein Next.js 16-Monorepo mit tRPC, Drizzle, PostgreSQL, Better Auth, AI SDK 6 über Vercel AI Gateway, sieben Locales, 93 Blog-Slugs, 651 lokalisierten JSON-Dateien, sechs Service-Seiten, einem WordPress Health Report-Tool und einem AI-Assistenten.

KI-gestützte Build-Geschwindigkeit entfaltet ihr Potenzial am besten innerhalb einer definierten Architektur. Diese Architektur hält den Code nach dem ersten Demo nützlich.

Zur weiteren Wirtschaftlichkeit lohnt sich der Beitrag Build vs. Buy Software 2026. Der gleiche Crossover gilt hier: temporäre Oberfläche mieten oder generieren, den Workflow der sich aufsummiert selbst bauen.

Die Entscheidungstabelle für 2026

Den meisten Teams stehen heute vier Pfade offen, nicht zwei. Die richtige Wahl hängt von Zielgruppe, Datenrisiko, Lebensdauer und Ownership ab.

Die Tabelle ist bewusst auf kontrollierten Scope ausgerichtet. Temporäre Arbeit gehört in Sites. Stabile, generische Workflows in No-Code. Sobald das Produkt ein eigenes Geschäftsgut werden muss, gehört es sauber gebaut.

Das ist die praktische Variante KI-gestützter Entwicklung: KI komprimiert den Weg zur lauffähigen Software, Engineering-Urteilsvermögen entscheidet, welche lauffähige Software eine echte Codebase verdient.

Eine 20-Minuten-Checkliste vor dem Build

Bevor das Team Codex, einen App-Builder oder eine Agentur beauftragt, lohnt es sich, diese Fragen schriftlich zu beantworten. Die Antworten entscheiden schneller über den richtigen Pfad als eine weitere Tool-Demo.

• Zielgruppe: Ist der Zugang auf Mitarbeitende in einem Workspace beschränkt, oder nutzen Kunden, Partner oder Auftragnehmer die App?
• Daten: Werden PII, Zahlungen, Verträge, Dateien, private Analytics oder operative Datensätze gespeichert?
• Lebensdauer: Interessiert diese App in 90 Tagen noch jemanden?
• Fehlerfall: Was passiert, wenn die App einen Geschäftstag lang falsch, nicht erreichbar oder veraltet ist?
• Integrationen: Wird direkter Zugang zu CRM, ERP, Datenbank, Payment-Processor oder interner API benötigt?
• Berechtigungen: Gibt es mehr als zwei Rollen, oder muss ein Nutzer Datensätze sehen, die ein anderer nicht sieht?
• Ownership: Muss der Source Code im eigenen Repository liegen, mit Tests, Dokumentation und Übergabepfad?

Für jedes Ja außerhalb der ersten Frage einen Punkt vergeben. Null bis zwei Punkte: Codex Sites oder No-Code zuerst ausprobieren. Drei bis vier Punkte: mit Sites prototypen, dann den Build scopen. Fünf oder mehr Punkte: die App ist bereits im Custom-Web-App-Bereich.

webvise baut die Projekte der rechten Spalte: eigenverantwortete Full-Stack-Anwendungen mit Source Code, Auth, Integrationen, Monitoring und einem Deployment-Pfad, den das Team dauerhaft nutzen kann. Wer abwägt, ob Codex Sites reicht oder ein Custom Build nötig ist: Die Checkliste-Antworten einsenden, und ich sage, welchen Pfad ich wählen würde.