Codex Sites vs. individuelle Web-Apps: Wann Sie 2026 welches nutzen sollten
Codex Sites ist eine nützliche Oberfläche für interne Apps, aber kein vollständiger Ersatz für Produktionssoftware. Hier ist die Entscheidungsgrenze für Teams, die zwischen Sites, AI-Buildern, No-Code und einer individuellen Web-App wählen.
Die Entscheidung Codex Sites vs. individuelle Web-App ist einfach: Nutzen Sie Codex Sites für interne Workspace-Apps, prüfbare Prototypen und temporäre Tools. Bauen Sie eine individuelle Web-App, wenn externe Nutzer, dauerhafte Geschäftsdaten, tiefe Auth-Anforderungen, Compliance, Integrationen oder Source-Code-Eigentum das Projekt bestimmen.
OpenAI hat am 2. Juni 2026 keine Webagenturen getötet. OpenAI hat die Ausrede getötet, dass ein Team einen Monat braucht, um eine erste funktionierende Version zu sehen.
Das ist relevant, wenn Ihr Team eine Idee in einem Dokument, einen Spreadsheet-Workflow oder ein Dashboard hat, das niemand bauen kann. Dieser Artikel gibt Ihnen die Entscheidungsgrenze, die Risiko-Checkliste und den Preisrahmen. Er trennt, was Codex Sites übernehmen sollte, von dem, was in eine produktionsreife individuelle Web-Anwendung gehört.
Codex Sites passt am besten zu internen Workspace-Apps. Denken Sie an Planer, Dashboards, Review-Hubs, Games und einmalige Tools, die Ihr Team hinter kontrolliertem Zugriff nutzt.
Jede Sites-Deployment-URL ist Produktion. OpenAIs Dokumentation sagt Teams, zuerst eine Version zu speichern, wenn sie vor einem Live-Deployment prüfen wollen.
Individuelle Web-Apps gewinnen weiter, wenn die App das Geschäft ist. Externe Nutzer, private Daten, tiefe Berechtigungen, direkte API-Integrationen und langfristiges Eigentum bewegen die Arbeit aus Sites heraus.
Der Käuferfehler ist, einen Prototyp Plattform zu nennen. Wir haben denselben Fehler in vibe-coded MVPs werden zu Tech Debt beschrieben.
webvise baut Full-Stack-Anwendungen ab 7.500 € in 4 bis 10 Wochen, wenn die Arbeit Source Code, Architektur, Monitoring und Übergabe braucht statt einer temporären Workspace-App.
Was Codex Sites tatsächlich liefert
OpenAI kündigte Codex Sites am 2. Juni 2026 an, zusammen mit Role Plugins und Annotations für gemeinsame Reviews. Die Ankündigung nennt mehr als 5 Millionen wöchentliche Nutzer von Codex. Die Nutzung durch Nichtentwickler wuchs im Vormonat um 3x und erreichte mehr als 20 Prozent der Nutzung.
Die Produktaussage ist nützlich, weil sie die Zielgruppe benennt. Codex ist nicht mehr nur eine Coding-Oberfläche für Entwickler. Es ist ein Workspace-Tool für Menschen mit einem Plan, einer Tabelle, einem Prozess oder einer groben Produktidee, die etwas Interaktives sehen wollen.
OpenAIs Codex Sites Dokumentation beschreibt einen gehosteten Workflow, in dem Codex Websites, Web-Apps und Games erstellen, speichern, deployen und prüfen kann. Sites-Projekte können D1 für relationale Daten, R2 für Dateispeicher, Workspace-authentifizierte Identität und konfigurierbare Zugriffsmodi nutzen.
Das wichtige Detail wird leicht übersehen: Jede Sites-Deployment-URL ist ein Produktions-Deployment. Wenn Sie vor dem Livegang prüfen wollen, sagt die Dokumentation, dass Sie eine Version ohne Deployment speichern sollen.
Die Entscheidungsgrenze sind Publikum und Eigentum
Die erste Frage ist nicht, ob Codex die Oberfläche bauen kann. Oft kommt es weit genug. Die erste Frage ist, wer vom Ergebnis abhängt, sobald die URL existiert.
Wenn das Publikum Ihr internes Team ist, der Zugriff im Workspace bleibt und ein Fehler nur eine Entscheidung verzögert, ist Sites ein starker Fit. Wenn das Publikum aus Kunden, Partnern, Prüfern oder zahlenden Nutzern besteht, trägt die Oberfläche ein anderes Risiko. Die App braucht dann Architektur, Support-Pfade, Observability und kontrollierte Änderungen.
Eigentum ist die zweite Linie. Ein temporäres Planungstool kann in einem gehosteten Workspace leben. Ein Kernprodukt sollte in Source Code leben, den Sie kontrollieren, mit Infrastruktur, die Ihr Team oder Ihre Agentur prüfen, testen und bewegen kann.
| Frage | Codex Sites Antwort | Individuelle Web-App Antwort |
|---|---|---|
| Wer nutzt es? | Interne Workspace-Nutzer | Kunden, Partner, Mitarbeitende und Admins |
| Was passiert bei einem Fehler? | Ein Meeting oder Review wird langsamer | Umsatz, Support, Vertrauen oder Compliance sind betroffen |
| Wem gehört der Code-Pfad? | OpenAI-gehosteter Projektworkflow | Ihr Repository, CI, Tests und Deployment-Pipeline |
| Wie lange soll es leben? | Tage bis Monate | Jahre |
| Welche Daten hält es? | Arbeitsdaten mit niedrigem Risiko | PII, Zahlungen, Verträge, Dateien oder operative Datensätze |
| Was ist das richtige Budget? | Teamzeit plus Plan-Zugriff | Ab 7.500 € für einen fokussierten Full-Stack-Build |
Wenn Ihre Antwort dreimal in die rechte Spalte fällt, behandeln Sie Sites als Discovery-Tool, nicht als Produktionsweg. Dort passt webvises Full-Stack-Anwendungsservice: Next.js, PostgreSQL, Better Auth, tRPC, Drizzle, Deployment, Monitoring und Übergabe als ein eigener Codebestand.
Wo Codex Sites gewinnt
Sites gewinnt, wenn die Kosten des Nicht-Sehens höher sind als die Kosten einer groben ersten Version. Ein Team kann ein Dashboard, eine Planungs-App, eine Simulation oder einen Review-Hub anfordern und das Ergebnis mit einer kontrollierten Zielgruppe teilen.
Eine echte Geschichte aus dem Launch ist die Veränderung, wer starten kann. Am 2026-06-02 rahmte OpenAI Codex für jede Rolle, nicht nur für Entwickler. Das zählt, weil viele nützliche interne Apps nie als Tickets beginnen. Sie beginnen als Finanzmodell, Launch-Plan oder unordentliches Operations-Sheet.
Die richtige Sites-Anfrage ist eng: Mach aus diesem Plan ein funktionierendes internes Tool, das unser Team heute prüfen kann. Die falsche Anfrage ist breit: Bau die Plattform, von der unsere Kunden die nächsten drei Jahre abhängen.
Interner Launch-Planer. Verwandeln Sie eine Launch-Checkliste in ein Statusboard mit Ownern, Terminen und Blockern.
Forecast-Sandbox. Machen Sie aus einem Spreadsheet-Modell Slider, Tabellen und gespeicherte Szenarien für ein Leadership-Review.
Training-Game. Bauen Sie eine kleine interaktive Übung für einen internen Workshop, ohne ein ganzes Produkt zu beauftragen.
Workflow-Prototyp. Lassen Sie Operations-Mitarbeitende den Prozess klicken, bevor jemand über Felder in einer Spezifikation streitet.
Temporäres Dashboard. Ziehen Sie einen begrenzten Datensatz in eine Review-Oberfläche für ein wöchentliches Meeting.
Diese Apps sind wertvoll. Sie sind aber auch begrenzt. Sobald sie zum Record of Truth werden, ändert sich die Entscheidung.
Wo individuelle Web-Apps weiter gewinnen
Individuelle Web-Apps gewinnen, wenn Software Teil des Betriebsmodells wird. Die App braucht Auth, die Sie erklären können, ein Datenmodell, das Ihrem Team gehört, Integrationen, die nicht von einem Prompt abhängen, und Fehlerbehandlung, die läuft, wenn niemand zusieht.
Bei webvise startet die Full-Stack-Basis bei 7.500 € und läuft für Produktionsanwendungen meist 4 bis 10 Wochen. Dieses Budget kauft Dinge, die eine Prompt-Demo auslässt: Datenbankarchitektur, API-Verträge, rollenbasierte Berechtigungen, CI/CD, Monitoring und einen Übergabepfad.
webvise.io ist der interne Beleg für das Modell, ohne sich auf externe Projektbelege zu stützen. Die Seite ist keine Broschüre. Sie 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 lokalisierte JSON-Dateien, sechs Service-Seiten, einem WordPress Health Report Tool und einem AI Assistant.
Die Lektion ist nicht, dass jede Business-Website so viel Maschinerie braucht. Die Lektion ist, dass AI-unterstützte Baugeschwindigkeit am besten innerhalb einer definierten Architektur funktioniert. Die Architektur hält den Code nach der ersten Demo nützlich.
Für die breitere Ökonomie lesen Sie Build vs Buy Software in 2026. Derselbe Crossover gilt hier: Mieten oder generieren Sie die temporäre Oberfläche, bauen Sie den Workflow, der sich verzinst.
Die Entscheidungstabelle 2026
Die meisten Teams haben jetzt vier Wege, nicht zwei. Die richtige Wahl hängt von Publikum, Datenrisiko, Lebensdauer und Eigentum ab.
| Weg | Am besten für | Vermeiden, wenn | Typischer Einsatz |
|---|---|---|---|
| Codex Sites | Interne Apps, Prototypen, Review-Tools, leichte Games | Externe Nutzer oder regulierte Daten davon abhängen | Stunden bis Tage |
| AI App Builder | Ideen-Demos, Gründer-Prototypen, Wegwerf-MVP-Validierung | Sie saubere Auth, Tests, Dateneigentum oder Übergabe brauchen | Stunden bis eine Woche |
| No-Code-Tools | Stabile Workflows, die in vorhandene Connectoren passen | Private APIs, eigene Geschäftsregeln oder viele Workflows zählen | Tage bis Wochen |
| Individuelle Web-App | Eigene Produkte, Portale, interne Plattformen, SaaS, komplexe Integrationen | Das Problem temporär oder noch nicht verstanden ist | 4 bis 10 Wochen ab 7.500 € |
Die Tabelle ist bewusst gegen Überbauung geneigt. Wenn die Arbeit temporär ist, nutzen Sie Sites. Wenn der Workflow stabil, aber generisch ist, nutzen Sie No-Code. Wenn das Produkt ein eigener Geschäftsasset werden muss, bauen Sie es sauber.
Das ist nicht anti-AI. Es ist die praktische Version AI-unterstützter Lieferung. Nutzen Sie AI, um den Weg zu funktionierender Software zu verkürzen, und nutzen Sie Engineering-Urteil, um zu entscheiden, welche funktionierende Software einen echten Codebestand verdient.
Eine 20-Minuten-Checkliste vor dem Build
Bevor Ihr Team Codex, einen App Builder oder eine Agentur bittet zu starten, beantworten Sie diese Fragen schriftlich. Die Antworten entscheiden den Weg schneller als eine weitere Tool-Demo.
Publikum: Ist der Zugriff auf Mitarbeitende in einem Workspace beschränkt, oder nutzen Kunden, Partner oder externe Auftragnehmer die App?
Daten: Speichert sie PII, Zahlungen, Verträge, Dateien, private Analytics oder operative Datensätze?
Lebensdauer: Wird diese App in 90 Tagen noch jemanden interessieren?
Fehler: Was passiert, wenn die App einen Geschäftstag lang falsch, nicht verfügbar oder veraltet ist?
Integrationen: Braucht sie direkten Zugriff auf CRM, ERP, Datenbank, Payment Processor oder interne API?
Berechtigungen: Gibt es mehr als zwei Rollen, oder muss ein Nutzer Datensätze sehen, die ein anderer nicht sehen darf?
Eigentum: Brauchen Sie den Source Code in Ihrem Repository, mit Tests, Dokumentation und Übergabepfad?
Geben Sie einen Punkt für jedes Ja außerhalb der ersten Frage. Null bis zwei Punkte heißt: Probieren Sie zuerst Codex Sites oder No-Code. Drei oder vier Punkte heißt: Prototypen Sie mit Sites und scopen Sie dann den Build. Fünf oder mehr heißt: Die App ist bereits im Gebiet individueller Web-Apps.
webvise baut die Projekte aus der rechten Spalte: eigene Full-Stack-Anwendungen mit Source Code, Auth, Integrationen, Monitoring und einem Deployment-Pfad, den Ihr Team weiter nutzen kann. Wenn Sie entscheiden, ob Codex Sites reicht oder ob das Projekt einen individuellen Build braucht, schicken Sie uns die Checklisten-Antworten, und wir sagen Ihnen, welchen Weg wir nehmen würden.
Die Praktiken von webvise sind an den ISO 27001- und ISO 42001-Standards ausgerichtet.