Codex Sites vs Custom Web Apps: When to Use Each in 2026

The Codex Sites vs custom web app decision is simple: use Codex Sites for internal workspace apps, reviewable prototypes, and temporary tools. Build a custom web app when external users, durable business data, auth depth, compliance, integrations, or source-code ownership decide the project.

OpenAI did not kill web agencies on June 2, 2026. It killed the excuse that a team needs a month to see a first working version.

That matters if your team has an idea stuck in a document, a spreadsheet workflow, or a dashboard nobody has time to build. This article gives you the decision line, the risk checklist, and the pricing frame. It separates what Codex Sites should own from what belongs in a production-grade custom web application.

• Codex Sites is best for internal workspace apps. Think planners, dashboards, review hubs, games, and one-off tools your team can use behind controlled access.

• Every Sites deployment URL is production. OpenAI's docs tell teams to save a version first when they want review before a live deployment.

• Custom web apps still win when the app is the business. External users, private data, deep permissions, direct API integrations, and long-term ownership move the work out of Sites.

• The buyer mistake is calling a prototype a platform. We covered the same failure mode in vibe-coded MVPs becoming tech debt.

• webvise builds full-stack applications from €7,500 in 4 to 10 weeks when the work needs source code, architecture, monitoring, and handover instead of a temporary workspace app.

What Codex Sites Actually Ships

OpenAI announced Codex Sites on June 2, 2026, alongside role plugins and annotations for shared review. The announcement says Codex has more than 5 million weekly users, with non-developer usage growing 3x in the previous month and reaching more than 20 percent of usage.

The product claim is useful because it names the audience. Codex is no longer only a coding surface for engineers. It is a workspace tool for people who have a plan, a spreadsheet, a process, or a rough product idea and want something interactive.

OpenAI's Codex Sites docs describe a hosted workflow where Codex can create, save, deploy, and inspect websites, web apps, and games. Sites projects can use D1 for relational data, R2 for file storage, workspace-authenticated identity, and configurable access modes.

The important detail is easy to miss: every Sites deployment URL is a production deployment. If you want to review before it becomes live, the docs say to save a version without deploying it.

The Decision Line Is Audience and Ownership

The first question is not whether Codex can build the interface. It can often get far enough. The first question is who depends on the result once the URL exists.

If the audience is your internal team, access is workspace-scoped, and failure means a delayed decision, Sites is a strong fit. If the audience is customers, partners, regulators, or paying users, the surface carries a different risk profile. The app now needs architecture, support paths, observability, and change control.

Ownership is the second line. A temporary planning tool can live inside a hosted workspace. A core product should live in source code you control, with infrastructure your team or agency can inspect, test, and move.

If your answer falls into the right column three times, treat Sites as a discovery tool, not the production path. That is where webvise's full-stack application service fits: Next.js, PostgreSQL, Better Auth, tRPC, Drizzle, deployment, monitoring, and handover as one owned codebase.

Where Codex Sites Wins

Sites wins when the cost of not seeing the workflow is higher than the cost of a rough first version. A team can ask for a dashboard, a planning app, a simulation, or a review hub and share the result with a controlled audience.

A real story from the launch is the change in who can start. On 2026-06-02, OpenAI framed Codex for every role, not only for engineers. That matters because many useful internal apps never start as tickets. They start as a finance model, a launch plan, or a messy operations sheet.

The right Sites request is narrow: turn this plan into a working internal tool our team can inspect today. The wrong request is broad: build the platform our customers will depend on for the next three years.

• Internal launch planner. Convert a launch checklist into a status board with owners, dates, and blockers.

• Forecast sandbox. Turn a spreadsheet model into sliders, tables, and saved scenarios for a leadership review.

• Training game. Build a small interactive exercise for an internal workshop without commissioning a full product.

• Workflow prototype. Let operations staff click through the process before anyone argues about fields in a spec.

• Temporary dashboard. Pull a limited dataset into a review surface for a weekly meeting.

These are valuable apps. They are also bounded apps. The moment they become the record of truth, the decision changes.

Where Custom Web Apps Still Win

Custom web apps win when the software becomes part of the operating model. The app needs auth you can reason about, a data model your team owns, integrations that do not depend on a prompt, and error handling that runs when nobody is watching.

At webvise, the full-stack baseline starts at €7,500 and usually runs 4 to 10 weeks for production applications. That budget buys things a prompt demo skips: database architecture, API contracts, role-based permissions, CI/CD, monitoring, and a handover path.

webvise.io is the internal proof of the model, without relying on outside project proof. The site is not a brochure. It is a Next.js 16 monorepo with tRPC, Drizzle, PostgreSQL, Better Auth, AI SDK 6 through Vercel AI Gateway, seven locales, 93 blog slugs, 651 localized JSON files, six service pages, a WordPress Health Report tool, and an AI assistant.

The lesson is not that every business website needs that much machinery. The lesson is that AI-assisted build speed works best inside a defined architecture. The architecture is what keeps the code useful after the first demo.

For the broader economics, read Build vs Buy Software in 2026. The same crossover applies here: rent or generate the temporary surface, build the workflow that compounds.

The 2026 Decision Table

Most teams now have four paths, not two. The right choice depends on audience, data risk, lifetime, and ownership.

The table is intentionally biased toward not overbuilding. If the work is temporary, use Sites. If the workflow is stable but generic, use no-code. If the product must become an owned business asset, build it properly.

That is not anti-AI. It is the practical version of AI-assisted delivery. Use AI to compress the path to working software, then use engineering judgment to decide which working software deserves a real codebase.

A 20-Minute Checklist Before You Build

Before your team asks Codex, an app builder, or an agency to start, answer these questions in writing. The answers decide the path faster than another tool demo.

• Audience: Is access limited to employees in one workspace, or will customers, partners, or contractors use it?

• Data: Does it store PII, payments, contracts, files, private analytics, or operational records?

• Lifetime: Will anyone care about this app in 90 days?

• Failure: What happens if the app is wrong, unavailable, or out of date for one business day?

• Integrations: Does it need direct access to your CRM, ERP, database, payment processor, or internal API?

• Permissions: Are there more than two roles, or does one user need to see records another user cannot?

• Ownership: Do you need the source code in your repository, with tests, docs, and a handover path?

Score one point for every yes outside the first question. Zero to two points means try Codex Sites or no-code first. Three or four points means prototype with Sites, then scope the build. Five or more means the app is already in custom-web-app territory.

webvise builds the right-column projects: owned full-stack applications with source code, auth, integrations, monitoring, and a deployment path your team can keep using. If you are deciding whether Codex Sites is enough or whether the project needs a custom build, send us the checklist answers and we will tell you which path we would take.