Codex Sites vs applicazioni web custom: quando usare ciascuna opzione nel 2026

La decisione Codex Sites vs applicazione web custom è semplice: usi Codex Sites per app interne di workspace, prototipi verificabili e tool temporanei. Costruisca un'applicazione web custom quando utenti esterni, dati aziendali durevoli, auth profonda, compliance, integrazioni o proprietà del codice sorgente decidono il progetto.

OpenAI non ha ucciso le agenzie web il 2 giugno 2026. OpenAI ha ucciso la scusa che un team abbia bisogno di un mese per vedere una prima versione funzionante.

Questo conta se il suo team ha un'idea bloccata in un documento, un workflow in un foglio di calcolo o una dashboard che nessuno ha tempo di costruire. Questo articolo offre la linea decisionale, la checklist dei rischi e il quadro di prezzo. Separa ciò che Codex Sites dovrebbe gestire da ciò che appartiene a un'applicazione web custom pronta per la produzione.

• Codex Sites è più adatto alle app interne di workspace. Pensi a planner, dashboard, hub di review, giochi e tool una tantum che il suo team può usare dietro accesso controllato.

• Ogni URL di deployment Sites è produzione. La documentazione OpenAI dice ai team di salvare prima una versione se vogliono fare review prima di un deployment live.

• Le applicazioni web custom vincono ancora quando l'app è il business. Utenti esterni, dati privati, permessi profondi, integrazioni API dirette e proprietà a lungo termine portano il lavoro fuori da Sites.

• L'errore del buyer è chiamare piattaforma un prototipo. Abbiamo trattato lo stesso errore in MVP vibe-coded che diventano debito tecnico.

• webvise costruisce applicazioni full-stack da 7.500 € in 4 a 10 settimane quando il lavoro richiede codice sorgente, architettura, monitoring e handover invece di un'app temporanea di workspace.

Cosa consegna davvero Codex Sites

OpenAI ha annunciato Codex Sites il 2 giugno 2026, insieme a role plugins e annotations per review condivise. L'annuncio dice che Codex ha oltre 5 milioni di utenti settimanali, con l'uso da parte di non sviluppatori cresciuto 3x nel mese precedente e arrivato a oltre il 20 per cento dell'uso.

La promessa di prodotto è utile perché nomina il pubblico. Codex non è più solo una superficie di coding per sviluppatori. È un tool di workspace per persone con un piano, un foglio di calcolo, un processo o un'idea prodotto grezza che vogliono vedere qualcosa di interattivo.

La documentazione Codex Sites di OpenAI descrive un workflow hosted in cui Codex può creare, salvare, deployare e ispezionare siti web, applicazioni web e giochi. I progetti Sites possono usare D1 per dati relazionali, R2 per file storage, identità autenticata del workspace e modalità di accesso configurabili.

Il dettaglio importante è facile da perdere: ogni URL di deployment Sites è un deployment di produzione. Se vuole fare review prima che diventi live, la documentazione dice di salvare una versione senza deployarla.

La linea decisionale è pubblico e proprietà

La prima domanda non è se Codex possa costruire l'interfaccia. Spesso può arrivare abbastanza lontano. La prima domanda è chi dipende dal risultato quando l'URL esiste.

Se il pubblico è il team interno, l'accesso è limitato al workspace e un errore significa una decisione ritardata, Sites è una buona scelta. Se il pubblico è composto da clienti, partner, auditor o utenti paganti, la superficie porta un altro profilo di rischio. L'app ora richiede architettura, percorsi di supporto, observability e controllo delle modifiche.

La proprietà è la seconda linea. Un tool temporaneo di pianificazione può vivere in un workspace hosted. Un prodotto core dovrebbe vivere in codice sorgente che Lei controlla, con infrastruttura che il suo team o la sua agenzia può ispezionare, testare e spostare.

Se la sua risposta cade tre volte nella colonna di destra, tratti Sites come tool di scoperta, non come percorso di produzione. Qui entra il servizio full-stack applications di webvise: Next.js, PostgreSQL, Better Auth, tRPC, Drizzle, deployment, monitoring e handover come una codebase posseduta.

Dove Codex Sites vince

Sites vince quando il costo di non vedere il workflow è più alto del costo di una prima versione grezza. Un team può chiedere una dashboard, un'app di pianificazione, una simulazione o un hub di review e condividere il risultato con un pubblico controllato.

Una storia reale del lancio è il cambiamento di chi può iniziare. Il 2026-06-02, OpenAI ha inquadrato Codex per ogni ruolo, non solo per gli sviluppatori. Questo conta perché molte app interne utili non iniziano mai come ticket. Iniziano come modello finanziario, piano di lancio o foglio operativo disordinato.

La richiesta giusta per Sites è stretta: trasformi questo piano in un tool interno funzionante che il nostro team possa ispezionare oggi. La richiesta sbagliata è ampia: costruisca la piattaforma da cui i nostri clienti dipenderanno per i prossimi tre anni.

• Planner interno di lancio. Converta una checklist di lancio in una board di stato con owner, date e blocker.

• Sandbox di forecast. Trasformi un modello spreadsheet in slider, tabelle e scenari salvati per una review di leadership.

• Gioco di training. Costruisca un piccolo esercizio interattivo per un workshop interno senza commissionare un prodotto completo.

• Prototipo di workflow. Faccia cliccare il processo al team operations prima che qualcuno discuta sui campi in una spec.

• Dashboard temporanea. Porti un dataset limitato in una superficie di review per una riunione settimanale.

Queste app hanno valore. Sono anche delimitate. Nel momento in cui diventano il record of truth, la decisione cambia.

Dove le applicazioni web custom vincono ancora

Le applicazioni web custom vincono quando il software diventa parte del modello operativo. L'app ha bisogno di auth su cui si possa ragionare, un modello dati posseduto dal team, integrazioni che non dipendono da un prompt e gestione errori che funzioni quando nessuno guarda.

Da webvise, la base full-stack parte da 7.500 € e di solito richiede 4 a 10 settimane per applicazioni di produzione. Quel budget compra cose che una demo da prompt salta: architettura database, contratti API, permessi basati sui ruoli, CI/CD, monitoring e percorso di handover.

webvise.io è la prova interna del modello, senza dipendere da una prova di progetto esterna. Il sito non è una brochure. È un monorepo Next.js 16 con tRPC, Drizzle, PostgreSQL, Better Auth, AI SDK 6 tramite Vercel AI Gateway, sette locales, 93 blog slugs, 651 file JSON localizzati, sei pagine servizio, un tool WordPress Health Report e un AI assistant.

La lezione non è che ogni sito aziendale abbia bisogno di così tanta meccanica. La lezione è che la velocità di build assistita da AI funziona meglio dentro un'architettura definita. L'architettura mantiene utile il codice dopo la prima demo.

Per l'economia più ampia, legga Build vs Buy Software in 2026. Lo stesso crossover vale qui: affitti o generi la superficie temporanea, costruisca il workflow che accumula valore.

La tabella decisionale 2026

La maggior parte dei team ora ha quattro percorsi, non due. La scelta giusta dipende da pubblico, rischio dati, durata e proprietà.

La tabella è volutamente inclinata contro l'overbuilding. Se il lavoro è temporaneo, usi Sites. Se il workflow è stabile ma generico, usi no-code. Se il prodotto deve diventare un asset aziendale posseduto, lo costruisca correttamente.

Questo non è anti-AI. È la versione pratica della delivery assistita da AI. Usi AI per accorciare il percorso verso software funzionante, poi usi giudizio ingegneristico per decidere quale software funzionante merita una vera codebase.

Una checklist di 20 minuti prima di costruire

Prima che il suo team chieda a Codex, a un app builder o a un'agenzia di iniziare, risponda per iscritto a queste domande. Le risposte decidono il percorso più velocemente di un'altra demo di tool.

• Pubblico: l'accesso è limitato ai dipendenti in un workspace, o la useranno clienti, partner o contractor?

• Dati: archivia PII, pagamenti, contratti, file, analytics private o record operativi?

• Durata: qualcuno si preoccuperà ancora di questa app tra 90 giorni?

• Errore: cosa succede se l'app è sbagliata, non disponibile o non aggiornata per un giorno lavorativo?

• Integrazioni: richiede accesso diretto a CRM, ERP, database, payment processor o API interna?

• Permessi: ci sono più di due ruoli, o un utente deve vedere record che un altro non può vedere?

• Proprietà: le serve il codice sorgente nel suo repository, con test, docs e percorso di handover?

Assegni un punto per ogni sì fuori dalla prima domanda. Zero a due punti significa: provi prima Codex Sites o no-code. Tre o quattro punti significa: prototipi con Sites, poi definisca lo scope della build. Cinque o più significa: l'app è già in territorio applicazione web custom.

webvise costruisce i progetti della colonna destra: applicazioni full-stack possedute con codice sorgente, auth, integrazioni, monitoring e un percorso di deployment che il suo team può continuare a usare. Se sta decidendo se Codex Sites basta o se il progetto ha bisogno di una build custom, ci invii le risposte della checklist e le diremo quale percorso prenderemmo.