Un sito può apparire completo e restare impossibile da consegnare. Il codice vive in un account personale, una chiave è nota a una sola persona, il database non ha una procedura di ripristino e il pulsante di pubblicazione nasconde passaggi manuali. La dimostrazione visiva non rivela nessuna di queste dipendenze.
IT-152 usa un sistema senza azienda. Il fascicolo contiene nove Specifica-ID, tre Sistema-ID, due ArchivioCodice-ID, quattro Linea-ID, sei PacchettoDipendenze-ID, tre AmbienteTecnico-ID, cinque Connettore-ID rivolti a endpoint fittizi, quattro Segreto-ID senza valore, venti Verifica-ID, due RilascioTecnico-ID, un Ripristino-ID e un PassaggioTecnico-ID da eseguire con identità neutre.
Ogni candidata deve trasformare gli input di IT-151 in un sistema tracciabile, introdurre una dipendenza, bloccare una build, distribuire dati sintetici, simulare un errore, tornare a una versione precedente e spiegare come recuperare il servizio. Il confronto osserva ciò che le pagine ufficiali permettono di chiedere. Non dichiara che questi passaggi siano già stati svolti.
Il confine editoriale è netto. IT-151 decide struttura informativa, intenzioni d'interfaccia, regole responsive e asset autorizzati. IT-152 può contestare una specifica ambigua, ma non ridisegnarla in silenzio. Allo stesso modo, SEO, campagne, profili locali e contenuti social restano nei rispettivi fascicoli e non diventano prove di sviluppo.
theStacc pubblica IT-152 e vende Managed Services, una proposta ampia che cita anche costruzione, hosting e gestione di siti. Non compare nella graduatoria perché la pagina ufficiale disponibile non documenta un processo autonomo di sviluppo web con architettura, repository, CMS, integrazioni, ambienti, verifiche, rilascio e recovery confrontabile con le otto fonti selezionate. Includerla richiederebbe colmare con supposizioni passaggi tecnici non pubblicati. Nessuna agenzia ha pagato per essere inclusa. Ogni descrizione di IT-152 è ricavata dalla pagina ufficiale indicata nella rispettiva scheda, verificata il 30 agosto 2026. Non abbiamo incaricato, intervistato o provato fornitori, sviluppatori, repository, branch, dipendenze, CMS, API, account, segreti, ambienti, pipeline, test, scansioni, distribuzioni, monitoraggio, backup, rollback, recovery, runbook, siti o infrastrutture. Non riportiamo prezzi, tempi, clienti, casi, testimonianze, premi, certificazioni, metriche o risultati. Restano da verificare entità contrattuale, disponibilità, copertura italiana, lingua, competenze assegnate, subfornitori, stack, licenze, accessi, proprietà, qualità, accessibilità effettiva, sicurezza effettiva, prestazioni effettive, condizioni di supporto e uscita. Le fonti di prima parte provano esclusivamente il perimetro dichiarato dal rispettivo fornitore. Non provano superiorità, idoneità o rendimento per una specifica impresa. Il banco di prova usa Specifica-ID, Sistema-ID, ArchivioCodice-ID, Linea-ID, PacchettoDipendenze-ID, AmbienteTecnico-ID, Connettore-ID, Segreto-ID, Verifica-ID, RilascioTecnico-ID, Ripristino-ID e PassaggioTecnico-ID astratti. Contiene dati sintetici privi di persone, endpoint fittizi non raggiungibili, configurazioni vuote e ruoli neutri. Non contiene imprese, lavoratori, clienti, edifici, cantieri, materiali, servizi, fotografie, marchi, indirizzi, richieste, preventivi, recensioni, contatti o risultati reali o inventati. Non formula affermazioni su installazione, ispezione, riparazione, sicurezza, permessi, garanzie o altre pratiche delle coperture. Nel cluster delle coperture, IT-147 copre il SEO, IT-148 i record locali, IT-149 i canali social e IT-150 il coordinamento multicanale. IT-151 consegna discovery, mappa, wireframe, regole visive, componenti, stati, contenuti e asset come input approvati o esplicitamente aperti. IT-152 inizia con architettura tecnica, codice, CMS, integrazioni, ambienti, verifiche, deployment, osservabilità, recovery e handoff. Mancano revisione tecnica indipendente, revisione linguistica italiana, controllo competente dell'accessibilità e un responsabile operativo. IT-152 conserva lo stato needs_human_review: senza i controlli elencati non può entrare nel flusso di pubblicazione automatica.
La risposta breve
XWP apre il confronto per migrazioni, architettura multisite, integrazioni, permessi, hardening, monitoraggio e gestione continuativa documentati. Vardot e Atomic Object seguono per architettura, CMS, API, CI/CD, test, deployment e supporto. WebDevStudios, thoughtbot, Mindgrub, Fingent e Alley offrono altri perimetri da provare sullo stesso sistema astratto.
- XWP: organizzazioni che vogliono interrogare nello stesso fascicolo architettura multisite, migrazione dei contenuti, integrazioni, accessi, cutover e gestione successiva
- Vardot: team che devono provare migrazione Drupal, content model, frontend disaccoppiato, governance, API, CI/CD, cutover e risposta operativa
- Atomic Object: organizzazioni che vogliono mettere alla prova backend cloud, integrazione dati, iterazioni, test automatizzati e manuali, distribuzione e manutenzione
- WebDevStudios: team che vogliono verificare strategia infrastrutturale, sviluppo WordPress, migrazioni eterogenee, API, aggiornamenti, copie e scansioni
- thoughtbot: organizzazioni che vogliono provare stack applicativo, integrazioni, cloud, CI/CD, affidabilità, supporto e trasferimento di conoscenza
- Mindgrub: team che devono interrogare più CMS e stack, workflow multilingue, integrazioni, architettura headless, accessibilità tecnica e monitoraggio
- Fingent: organizzazioni che vogliono discutere applicazioni custom, frontend e backend, API, modernizzazione, tecnologia open source, deployment e supporto
- Alley: team che vogliono provare un perimetro più stretto su software custom, piattaforma o CMS, migrazione e sistemi orientati alla pubblicazione
Un sistema astratto che rende visibili le dipendenze prima del contratto
Specifica-ID non è una frase nel preventivo. Ogni record contiene input, fonte, stato, criterio osservabile, dipendenza, ruolo autorizzato e conseguenza del mancato rispetto. Un requisito proveniente da IT-151 conserva il collegamento all'artefatto di design. Una supposizione tecnica rimane proposta finché il responsabile indicato non la accetta.
Sistema-ID divide il prodotto in responsabilità tecniche, non in pagine promozionali. Frontend, CMS, archivio dei contenuti, servizio di invio, media e telemetria possono diventare sistemi distinti soltanto quando confini, dati, proprietari e modalità di errore sono descritti. Aggiungere un servizio per moda introduce costo operativo e un nuovo punto di guasto.
Il diagramma di architettura deve essere leggibile insieme al registro. Ogni freccia indica protocollo, direzione, dati ammessi, autenticazione prevista, timeout, comportamento degradato e responsabile. Un rettangolo chiamato cloud non spiega dove vivono stato, configurazione, log o backup e non basta per accettare il disegno.
ArchivioCodice-ID registra organizzazione proprietaria, repository, visibilità, branch predefinito, regole di fusione, revisori di ruolo, automazioni e artefatti prodotti. Nel campione nessun account appartiene a una persona reale. Il fornitore deve dimostrare che un'identità del committente conserva controllo amministrativo e cronologia.
Linea-ID collega una modifica a Specifica-ID, file toccati, dipendenze, verifiche richieste e decisione di revisione. Una correzione non entra nel ramo protetto perché funziona sul computer di chi la scrive. La prova richiede una seconda identità, una revisione tracciata e un esito automatico ripetibile.
PacchettoDipendenze-ID distingue codice diretto, libreria, plugin, tema, servizio remoto e strumento di build. Registra versione, licenza dichiarata dalla fonte del pacchetto, motivo, proprietario, aggiornamento, rimozione e comportamento se il servizio scompare. Il protocollo non attribuisce sicurezza a una versione mai analizzata.
Il CMS riceve un modello di contenuto, non soltanto campi liberi. Tipo, obbligatorietà, formato, relazione, stato di pubblicazione, permesso, migrazione e fallback rimangono collegati. I record sintetici mostrano vuoto, bozza, contenuto incompleto e riferimento mancante senza inventare un servizio di coperture.
Connettore-ID descrive una integrazione verso un endpoint non raggiungibile. Contratto dati, autenticazione, rate limit da confermare, timeout, retry, idempotenza, errore, log e disattivazione devono essere espliciti. La demo usa risposte sintetiche controllate. Non chiama CRM, strumenti di analisi o sistemi di clienti.
Segreto-ID non contiene mai il valore. Indica sistema, ambiente, scopo, custode di ruolo, posizione autorizzata, rotazione prevista, revoca e dipendenze. Una chiave incollata nel repository o in una chat fallisce il test anche se l'integrazione sembra funzionare. I log devono evitare di riprodurla.
AmbienteTecnico-ID separa sviluppo, anteprima e produzione per dati, domini, configurazione, credenziali, accessi e distribuzione. Il campione non presume che debbano esistere esattamente tre ambienti. Chiede al fornitore di motivare il modello e di impedire che contenuto o segreti di produzione entrino nelle prove.
La pipeline trasforma un commit identificato in un artefatto identificato. Installazione deterministica, analisi statica pertinente, build, verifiche automatizzate, pubblicazione dell'artefatto e autorizzazione al rilascio hanno esiti separati. Un comando manuale può esistere, ma deve apparire nel runbook con prerequisiti e responsabilità.
Verifica-ID collega una condizione a livello, dati, ambiente, risultato atteso, esito e prova conservata. Test unitari, integrazione, sistema, accessibilità tecnica, prestazioni e controlli di sicurezza non sono equivalenti. Il protocollo chiede quali siano pertinenti senza dichiarare certificazione, copertura completa o assenza di vulnerabilità.
Il comportamento responsive parte dalle Vista-ID approvate in IT-151, ma viene osservato nel codice. Ordine, focus, errore, contenuto lungo, zoom e uso da tastiera richiedono controlli tecnici distinti. Superare uno scanner non dimostra conformità. Gli esiti aperti rimangono assegnati a un revisore competente.
RilascioTecnico-ID contiene commit, artefatto, configurazione, migrazione, approvatore, finestra, controlli precedenti e successivi, soglia di arresto e comunicazione. Pubblicare non significa accettare. Se il controllo sintetico fallisce, il record deve dire chi ferma la sequenza e quale stato conserva il servizio.
Il rollback torna a un artefatto o a una configurazione precedente quando ciò è tecnicamente compatibile. Non cancella automaticamente una migrazione dei dati. Ripristino-ID, invece, descrive come ricostruire stato o dati da una copia controllata. Confondere le due procedure produce una promessa che potrebbe non essere eseguibile.
Una copia non è un recupero provato. Il campione richiede origine, frequenza proposta, cifratura da confermare, destinazione, conservazione, accesso, verifica e procedura di restore. I dati sono sintetici. Il risultato indica soltanto che quel fascicolo può essere ripristinato nel contesto di prova.
L'osservabilità registra segnali tecnici utili e minimizza i dati. Disponibilità, errori, code, tempi e scadenze possono avere soglie, ma non ricevono numeri inventati. Ogni avviso indica destinatario di ruolo, orario, priorità, procedura e chiusura. Un pannello senza azione definita è decorazione operativa.
Il registro degli incidenti usa una simulazione controllata. Evento, impatto tecnico, rilevazione, decisione, mitigazione, evidenza e azione successiva restano ordinati. Non simula clienti o emergenze. Serve a verificare se log, alert, runbook e autorità permettono a un nuovo operatore di orientarsi.
PassaggioTecnico-ID elenca repository, configurazioni, ambienti, domini, dipendenze, integrazioni, pannelli, copie, runbook, debiti e accessi. Ogni voce ha proprietario istituzionale, formato, stato e prova. Una cartella compressa senza cronologia o istruzioni non sostituisce una consegna operativa.
La revoca conclude il test. Prima un secondo account clona, installa, costruisce, distribuisce, legge i segnali e segue il Ripristino-ID. Poi si rimuove l'identità del fornitore e si controllano token, utenti, automazioni e servizi collegati. La pagina non sostiene che alcuna agenzia abbia superato questa sequenza.
Prove di adeguatezza al settore da richiedere
- Specifica-ID collega input, fonte, stato, criterio, dipendenza e responsabile.
- Sistema-ID rende visibili confini, flussi, stato, configurazioni e modalità di errore.
- ArchivioCodice-ID e Linea-ID conservano proprietà, branch, review e verifiche.
- PacchettoDipendenze-ID registra versione, motivo, licenza, aggiornamento e uscita.
- AmbienteTecnico-ID separa dati, segreti, configurazioni, accessi e deployment.
- Connettore-ID definisce contratto dati, timeout, errore, log e disattivazione.
- RilascioTecnico-ID distingue distribuzione, controllo, arresto e rollback.
- PassaggioTecnico-ID prova repository, runbook, recovery e revoca con un altro account.
Come abbiamo valutato i fornitori
La graduatoria misura sei aree documentate: architettura e migrazione, repository e implementazione, CMS e integrazioni, ambienti e verifiche, rilascio e osservabilità, supporto e passaggio tecnico. Le fonti sono dichiarazioni dei fornitori sui propri servizi. Non sono test indipendenti e non dimostrano risultati.
XWP apre perché la pagina Services descrive migrazioni WordPress, architettura multisite, build end to end, formazione, tassonomie, redirect, integrazioni, workflow, data mapping, cutover, caching, CDN, permessi, audit trail, hardening, monitoraggio e gestione della piattaforma. Promesse commerciali e risultati sono esclusi.
Vardot documenta sviluppo e migrazione Drupal, architettura enterprise, caching, CDN, CI/CD, governance per ruoli, Drupal headless, frontend React, Next.js e Vue, modellazione dei contenuti, redirect, integrità dei dati, cutover, API e integrazioni. Certificazioni, numeri e affermazioni di conformità non entrano nel confronto.
Atomic Object pubblica backend cloud, storage, integrazione con sistemi dati, applicazioni responsive, pratiche che richiamano NIST e OWASP, test unitari e di sistema automatizzati, test funzionali manuali, iterazioni settimanali, deployment e manutenzione. Non assumiamo che tali pratiche garantiscano sicurezza o qualità.
WebDevStudios e thoughtbot rendono visibili strategia tecnica, WordPress custom, audit, migrazioni, API, aggiornamenti, backup, cloud, CI/CD, platform engineering, reliability, manutenzione e trasferimento di conoscenza. Ogni voce resta da convertire in oggetti, criteri e responsabilità contrattuali.
Mindgrub, Fingent e Alley completano il campo con CMS, stack, integrazioni, accessibilità nel processo, monitoraggio, web application, modernizzazione, supporto, software custom e migrazione dati. Casi, clienti, partner status, premi, metriche, velocità e risultati non influenzano l'ordine.
| Criterio | Peso | Che cosa ha contato |
|---|---|---|
| Architettura e tracciabilità | Priorità alta | Requisiti, sistemi, dati, confini, dipendenze e decisioni conservano collegamenti verificabili. |
| Repository e implementazione | Priorità alta | Proprietà, branch, review, build e artefatti non dipendono da un account personale. |
| CMS, API e configurazione | Priorità alta | Modelli, contratti dati, segreti, errori e disattivazione sono espliciti. |
| Ambienti e verifiche | Priorità alta | Dati, accessi, test e prove tecniche restano separati per contesto e scopo. |
| Rilascio e operazioni | Priorità alta | Distribuzione, controllo, osservabilità, rollback e recovery hanno procedure distinte. |
| Handoff e revoca | Priorità alta | Un secondo account può operare il campione prima che il fornitore perda gli accessi. |
Ogni fornitore doveva soddisfare gli stessi requisiti minimi prima che la sua posizione venisse presa in considerazione.
- Ogni candidata doveva avere una pagina ufficiale di sviluppo web o servizi tecnici raggiungibile il 30 agosto 2026.
- La fonte doveva documentare almeno architettura, codice, CMS, migrazione, API, ambienti, test, rilascio, supporto o gestione tecnica.
- Discovery visiva, wireframe, direzione UI e approvazione del design restano input di IT-151 e non aumentano la posizione.
- SEO, campagne, social media, lead generation, branding e produzione editoriale non sono trattati come sviluppo.
- Prezzi, tempi, clienti, casi, testimonianze, certificazioni, partner status, metriche, prestazioni e risultati sono esclusi.
- La menzione di enterprise o di un settore prova soltanto il modo in cui il fornitore presenta il servizio.
- theStacc è esclusa perché la fonte disponibile non descrive un processo tecnico autonomo comparabile.
L’elenco dei fornitori analizzato
Le posizioni derivano dalla metodologia pubblicata e dalla data di chiusura delle fonti, non sono una garanzia di risultato. Ogni scheda indica la migliore adeguatezza e il limite che con maggiore probabilità cambia una decisione d’acquisto.
XWP
Punti di forza documentati
- Migrazione e data mapping documentati.
- Multisite, caching e CDN visibili.
- Permessi, audit trail e hardening espliciti.
- Gestione, patch e monitoraggio pubblicati.
Limiti da verificare
- Nessun sistema viene provato.
- Proprietà e accessi da contrattare.
- Sicurezza effettiva non dimostrata.
- Italia e risultati restano aperti.
XWP è prima perché la pagina Services documenta migrazioni WordPress, architettura multisite, build end to end, training, migrazione di contenuti e tassonomie, redirect, integrazioni, workflow, data mapping, cutover, caching, CDN, permessi per ruolo, audit trail, hardening, vulnerability monitoring, aggiornamenti, patch, monitoraggio, QA automatizzata e avvisi. IT-152 esclude risultati, revenue, conversioni e status commerciali. La fonte non prova Italia, coperture, disponibilità, proprietà, qualità, sicurezza effettiva o esiti.
Consegnate i tre Sistema-ID e chiedete che l'architettura multisite mostri isolamento, ruoli, contenuti condivisi, configurazioni e modalità di guasto. Una scelta WordPress non viene accettata per familiarità. Deve collegarsi a Specifica-ID, dipendenze, responsabilità operative e piano di uscita.
Inserite nel CMS record sintetici con tassonomia incoerente, riferimento assente e redirect in conflitto. Data mapping e content migration dovrebbero produrre regole, eccezioni, conteggi e controlli ripetibili. Nessuna pagina o servizio reale viene aggiunto per rendere completa la dimostrazione.
Usate Connettore-ID fittizi e un ruolo con permesso eccessivo. Chiedete access control, audit trail, caching e CDN come configurazioni versionate. Hardening e vulnerability monitoring presenti sulla fonte diventano domande e Verifica-ID, non una dichiarazione che il sistema sia sicuro.
Eseguite un cutover sintetico, bloccate un controllo e tornate all'artefatto precedente. Poi fate applicare aggiornamento, patch, alert e runbook da un secondo account. Il primo posto riflette l'ampiezza tecnica pubblicata, non una prova pratica o una raccomandazione assoluta.
Fonti sui fornitori: XWP, Services ufficiale, consultato il 30.08.2026
Vardot
Punti di forza documentati
- Drupal development e migration espliciti.
- Architettura, CDN e CI/CD pubblicati.
- Headless e content model documentati.
- API, patch e incident response visibili.
Limiti da verificare
- Certificazioni escluse.
- Conformità non assunta.
- Accessi da verificare.
- Italia e qualità restano aperti.
Vardot è seconda perché la pagina Web Development documenta sviluppo e migrazione Drupal, enterprise architecture, caching, CDN, CI/CD, role based governance, Drupal headless o decoupled, frontend React, Next.js e Vue, content modeling, redirect, data integrity, cutover, integrazioni CRM, ERP, DAM, analytics e identity, API, monitoring, patching e incident response. IT-152 esclude certificazioni, partner status, quantità, paesi, promesse di sicurezza, conformità, prestazioni e risultati. Restano non provati Italia, coperture, proprietà e qualità.
Date a Vardot due opzioni di Sistema-ID, una Drupal integrata e una disaccoppiata. La proposta deve mostrare flussi, superfici operative, dipendenze frontend, caching, responsabilità e modalità degradata. Il nome headless non sostituisce una ragione legata alle Specifica-ID del campione.
Caricate contenuti sintetici con relazioni incomplete. Content modeling, migration, redirect e data integrity dovrebbero produrre mapping, eccezioni e verifiche prima del cutover. Chiedete come conservare identificatori e cronologia senza attribuire qualità ai dati mai elaborati.
Configurate Connettore-ID simulati per CRM, DAM e identity. L'agenzia deve descrivere contratto, autenticazione, timeout, errore, osservabilità e spegnimento. Nessuna integrazione esterna viene chiamata. Le API documentate sulla fonte sono un perimetro da interrogare, non un'integrazione consegnata.
Fermate una pipeline CI/CD e aprite un incidente controllato dopo il rilascio. Monitoraggio, patching e incident response devono collegarsi a ruoli e runbook. La seconda posizione deriva dalla continuità del processo pubblicato, non da certificazioni o risultati dichiarati.
Fonti sui fornitori: Vardot, Web Development ufficiale, consultato il 30.08.2026
Atomic Object
Punti di forza documentati
- Backend cloud e storage documentati.
- Integrazione dati pubblicata.
- Test automatici e manuali espliciti.
- Deployment e supporto visibili.
Limiti da verificare
- Riferimenti di sicurezza non certificano.
- Repository da contrattare.
- Infrastruttura non verificata.
- Italia e risultati restano aperti.
Atomic Object è terza perché la pagina Web App Development documenta cloud backend e storage, integrazione con enterprise data systems, responsive web apps, pratiche di sicurezza che fanno riferimento a NIST e OWASP, unit e system test automatizzati, functional test manuali, technology strategy, iterazioni settimanali, deployment nell'infrastruttura del cliente o su hosting di terzi e maintenance o support. IT-152 esclude anzianità, conteggi, testimonianze e risultati. La fonte non prova Italia, coperture, sicurezza, proprietà o qualità.
Consegnate Specifica-ID incomplete alla technology strategy e chiedete due architetture motivate. Backend cloud, storage e responsive app devono mostrare dati, dipendenze, costo operativo da quotare e uscita. Il campione non autorizza l'invenzione di utenti, flussi commerciali o informazioni del settore.
Collegate un Connettore-ID a un sistema dati simulato che restituisce record malformati. L'implementazione dovrebbe delimitare schema, validazione, timeout, retry e comportamento visibile. Un errore esterno non deve trasformarsi in contenuto plausibile o perdersi senza evidenza.
Create Verifica-ID per unità, sistema e funzione manuale, ciascuna con scopo e prova. I riferimenti NIST e OWASP presenti sulla fonte guidano domande su controlli pertinenti, ma non certificano il campione e non eliminano la revisione indipendente.
Dopo due iterazioni, distribuite lo stesso artefatto prima in infrastruttura controllata e poi in un ambiente terzo simulato. Chiedete differenze di configurazione, accesso, rollback e supporto. La terza posizione riconosce test e deployment pubblicati, non qualità osservata.
Fonti sui fornitori: Atomic Object, Web App Development ufficiale, consultato il 30.08.2026
WebDevStudios
Punti di forza documentati
- Strategia tecnica documentata.
- WordPress custom e audit espliciti.
- Migrazioni e API visibili.
- Aggiornamenti e backup pubblicati.
Limiti da verificare
- Scalabilità non provata.
- Frequenze da contrattare.
- Recovery da dimostrare.
- Italia e risultati restano aperti.
WebDevStudios è quarta perché la pagina Services documenta technical strategy e infrastructure consulting, custom WordPress development, code audits, content migration da database, API ed exported files, API integrations, scalability e performance, ongoing support, aggiornamenti di core, plugin e temi, scheduled offsite backups, regular security scans e headless WordPress. IT-152 esclude testimonianze, traffico, superiorità e risultati. La fonte non prova Italia, coperture, sicurezza effettiva, frequenza contrattuale, proprietà o qualità.
Consegnate il diagramma incompleto alla technical strategy. Chiedete che WordPress integrato e headless siano confrontati su dipendenze, build, hosting, content preview, failure mode e manutenzione. Nessuna opzione riceve punti soltanto perché appare più moderna.
Create tre sorgenti di migrazione sintetiche, database, API e file esportato, con lo stesso record in forme diverse. Il piano deve scegliere autorità, mapping, deduplica, errori, verifica e ripetibilità. Una migrazione completata non prova che il contenuto sia corretto o autorizzato.
Introducete una API instabile e un plugin con versione obsoleta. Code audit e API integration dovrebbero produrre evidenze, priorità, decisioni e percorso di rimozione. Scalability, performance e security scan diventano verifiche circoscritte, non qualità globale.
Chiedete una copia offsite e seguite il restore su dati sintetici. Poi applicate aggiornamenti di core, plugin e tema in un ambiente separato, bloccando il rilascio se una Verifica-ID fallisce. Il quarto posto non conferma che supporto o procedure siano già inclusi.
Fonti sui fornitori: WebDevStudios, Services ufficiale, consultato il 30.08.2026
thoughtbot
Punti di forza documentati
- Più stack web pubblicati.
- DevOps, cloud e CI/CD visibili.
- Platform engineering documentata.
- Knowledge transfer esplicito.
Limiti da verificare
- Promesse escluse.
- Repository non provato.
- Supporto da definire.
- Italia e risultati restano aperti.
thoughtbot è quinta perché la pagina Services documenta web development con Ruby on Rails, Hotwire, React ed Elixir, integrations, DevOps, cloud e CI/CD, platform engineering e site reliability, support and maintenance, team augmentation, maintainability, tools e knowledge transfer dopo l'engagement. IT-152 esclude recensioni e affermazioni promozionali su velocità o qualità. La fonte non prova Italia, coperture, repository del cliente, verifiche specifiche, proprietà o risultati.
Fornite quattro Linea-ID e chiedete quale stack risponde alle Specifica-ID senza trasformare Rails, Hotwire, React o Elixir in una preferenza astratta. La decisione deve includere dipendenze, competenze operative, aggiornamento, osservabilità e possibilità di trasferimento.
Collegate una integrazione fittizia e cambiatene il contratto. DevOps, cloud e CI/CD dovrebbero rendere visibili configurazione, test, build, deployment e rollback. La pipeline deve fallire in modo comprensibile e non richiedere una credenziale personale per ripartire.
Usate platform engineering e site reliability per definire segnali, runbook e responsabilità del campione. Nessun obiettivo numerico viene inventato. Il fornitore dovrebbe spiegare quali dati raccogliere, come minimizzarli e quando un avviso richiede azione.
Prima della fine dell'engagement, fate clonare, costruire e distribuire da un team neutro. Tools, maintainability e knowledge transfer devono tradursi in PassaggioTecnico-ID con prove. La quinta posizione riflette un'offerta ampia, non la facilità reale di manutenzione.
Fonti sui fornitori: thoughtbot, Services ufficiale, consultato il 30.08.2026
Mindgrub
Punti di forza documentati
- Più CMS documentati.
- Workflow e integrazioni pubblicati.
- Headless e stack visibili.
- Testing e monitoraggio espliciti.
Limiti da verificare
- Partner claim esclusi.
- Stack da scegliere.
- Repository non dimostrato.
- Italia e qualità restano aperti.
Mindgrub è sesta perché la pagina Websites documenta WordPress VIP, Drupal, ecommerce, .NET, Sitecore e Optimizely, workflow multilingue e di contenuto, integrations, headless CMS, PHP, JavaScript, Node, Angular e React Native, accessibility testing, analytics monitoring, discovery, development e support. IT-152 esclude partner claim, compliance assertion, casi e risultati. La fonte non prova Italia, coperture, conformità, repository, proprietà o qualità.
Consegnate un content model sintetico con varianti linguistiche vuote. Chiedete come WordPress, Drupal, Sitecore oppure Optimizely gestirebbero workflow, relazioni, anteprima, permessi ed export. Il confronto non decide la piattaforma e non attribuisce al campione contenuti tradotti.
Separate frontend e CMS con Connettore-ID. PHP, JavaScript, Node e Angular sono tecnologie pubblicate, ma ogni proposta deve mostrare build, contratto dati, fallback, aggiornamento e responsabilità. Headless non viene accettato se amplia il sistema senza una Specifica-ID pertinente.
Create Verifica-ID per tastiera, focus, errori e contenuto lungo e aggiungete analytics monitoring con eventi sintetici. Accessibility testing non equivale a conformità e analytics non implica tracciamento indiscriminato. Scopo, dati e accessi restano aperti.
Chiedete supporto su una dipendenza simulata e fate eseguire il runbook da un secondo ruolo. La sesta posizione deriva dall'ampiezza di CMS e stack visibile, non da partner status o un progetto osservato.
Fonti sui fornitori: Mindgrub, Websites ufficiale, consultato il 30.08.2026
Fingent
Punti di forza documentati
- Custom development documentato.
- Frontend, backend e API visibili.
- Modernizzazione e re-engineering pubblicati.
- Supporto e maintenance espliciti.
Limiti da verificare
- Test poco dettagliati.
- Repository da verificare.
- Sicurezza non assunta.
- Italia e risultati restano aperti.
Fingent è settima perché la pagina Web Application Development documenta custom web application development, modernization, responsive web design, UI/UX, wireframe, prototipi, open source web development e re-engineering, support and maintenance. La stessa pagina presenta frontend, backend, API development e un processo dalla discovery al deployment. IT-152 esclude promesse commerciali, esperienza, conteggi e risultati. La fonte non prova Italia, coperture, repository, test specifici, proprietà, sicurezza effettiva o qualità.
Consegnate una applicazione astratta con frontend, backend e due Connettore-ID. Chiedete che il custom development separi Sistema-ID, dati, autenticazione, configurazione e modalità degradata. Wireframe e prototipi restano input di IT-151 e non vengono rivalutati come prova tecnica.
Aggiungete un PacchettoDipendenze-ID non più mantenuto. La modernizzazione deve proporre inventario, compatibilità, migrazione progressiva, verifiche e uscita, senza promettere prestazioni o sicurezza. Open source e re-engineering richiedono licenze, versioni e manutentore.
Simulate una modifica API che rompe il frontend. Il processo dovrebbe aggiornare contratto, test, build e documentazione prima del deployment. Chiedete evidenza distinta per frontend, backend e integrazione, perché una schermata funzionante non dimostra la correttezza del servizio.
Dopo il rilascio sintetico, assegnate un errore al supporto e fate seguire il runbook. Maintenance deve avere perimetro, priorità, accessi, finestre e consegna. Il settimo posto riflette capacità pubblicate in modo generale, non una minore qualità osservata.
Fonti sui fornitori: Fingent, Web Application Development ufficiale, consultato il 30.08.2026
Alley
Punti di forza documentati
- Software custom documentato.
- Piattaforme e CMS visibili.
- Data migration esplicita.
- Perimetro publishing pubblicato.
Limiti da verificare
- UX resta in IT-151.
- Repository non dettagliato.
- Recovery da verificare.
- Italia e qualità restano aperti.
Alley è ottava perché la pagina Services documenta custom enterprise software development, platforms and CMS, data migration e sistemi orientati al publishing. La fonte include anche UX e audience research, che appartengono a IT-151 e non aumentano la posizione tecnica. IT-152 esclude clienti, casi, affermazioni promozionali e risultati. La pagina scelta fornisce meno dettagli su repository, ambienti, test, rilascio, recovery e supporto. Non prova Italia, coperture, proprietà o qualità.
Date ad Alley i tre Sistema-ID e chiedete quale richieda software custom e quale possa restare configurazione di piattaforma o CMS. Ogni scelta deve collegare responsabilità, dati e dipendenze. Il termine enterprise non aggiunge requisiti o scala al campione astratto.
Create una migrazione con identificatori duplicati e relazioni mancanti. Il piano deve rendere visibili mapping, trasformazioni, eccezioni, controlli e possibilità di ripetere il caricamento. La fonte documenta data migration, ma non dimostra come verrebbe eseguita in questo incarico.
Usate un flusso editoriale sintetico per distinguere modello, permessi, preview e pubblicazione. Audience research e UX vengono consegnate da IT-151 e non colmano una lacuna tecnica. Il fornitore deve respingere l'input ambiguo oppure aprire una Specifica-ID.
Richiedete esplicitamente repository, branch, ambienti, verifiche, deployment, osservabilità, recovery e PassaggioTecnico-ID, perché la fonte scelta non li dettaglia. L'ottavo posto indica evidenza pubblica più stretta, non una valutazione della capacità reale.
Fonti sui fornitori: Alley, Services ufficiale, consultato il 30.08.2026
Confronta il flusso di lavoro sulla tua attività
Esamina i servizi gestiti, i controlli di approvazione, le destinazioni di pubblicazione e i limiti dichiarati di theStacc prima di scegliere.
Otto perimetri tecnici sullo stesso sistema incompleto
La tabella converte soltanto ciò che le fonti ufficiali dichiarano in prove da richiedere. Non attribuisce qualità, disponibilità, proprietà, sicurezza, conformità, copertura italiana, esperienza con coperture o risultati.
| Fornitore | Modello di erogazione | Ambito documentato | Ideale per | Limite principale |
|---|---|---|---|---|
| XWP | Da confermare con il fornitore. | WordPress e multisite · Migrazione, permessi, cutover · Gestione e monitoraggio | organizzazioni che vogliono interrogare nello stesso fascicolo architettura multisite, migrazione dei contenuti, integrazioni, accessi, cutover e gestione successiva | Nessun sistema viene provato. Proprietà e accessi da contrattare. Sicurezza effettiva non dimostrata. Italia e risultati restano aperti. |
| Vardot | Da confermare con il fornitore. | Drupal e headless · Content model, API, CI/CD · Patching e incident response | team che devono provare migrazione Drupal, content model, frontend disaccoppiato, governance, API, CI/CD, cutover e risposta operativa | Certificazioni escluse. Conformità non assunta. Accessi da verificare. Italia e qualità restano aperti. |
| Atomic Object | Da confermare con il fornitore. | Web app e backend cloud · Test automatici e manuali · Deployment e manutenzione | organizzazioni che vogliono mettere alla prova backend cloud, integrazione dati, iterazioni, test automatizzati e manuali, distribuzione e manutenzione | Riferimenti di sicurezza non certificano. Repository da contrattare. Infrastruttura non verificata. Italia e risultati restano aperti. |
| WebDevStudios | Da confermare con il fornitore. | WordPress custom · Audit, migrazione e API · Aggiornamenti, copie e scansioni | team che vogliono verificare strategia infrastrutturale, sviluppo WordPress, migrazioni eterogenee, API, aggiornamenti, copie e scansioni | Scalabilità non provata. Frequenze da contrattare. Recovery da dimostrare. Italia e risultati restano aperti. |
| thoughtbot | Da confermare con il fornitore. | Rails, React ed Elixir · Cloud, CI/CD e reliability · Supporto e knowledge transfer | organizzazioni che vogliono provare stack applicativo, integrazioni, cloud, CI/CD, affidabilità, supporto e trasferimento di conoscenza | Promesse escluse. Repository non provato. Supporto da definire. Italia e risultati restano aperti. |
| Mindgrub | Da confermare con il fornitore. | CMS e stack multipli · Headless, integrazioni e test · Monitoraggio e supporto | team che devono interrogare più CMS e stack, workflow multilingue, integrazioni, architettura headless, accessibilità tecnica e monitoraggio | Partner claim esclusi. Stack da scegliere. Repository non dimostrato. Italia e qualità restano aperti. |
| Fingent | Da confermare con il fornitore. | Web application custom · API e modernizzazione · Deployment e manutenzione | organizzazioni che vogliono discutere applicazioni custom, frontend e backend, API, modernizzazione, tecnologia open source, deployment e supporto | Test poco dettagliati. Repository da verificare. Sicurezza non assunta. Italia e risultati restano aperti. |
| Alley | Da confermare con il fornitore. | Software custom e CMS · Migrazione dati · Dettagli operativi da chiedere | team che vogliono provare un perimetro più stretto su software custom, piattaforma o CMS, migrazione e sistemi orientati alla pubblicazione | UX resta in IT-151. Repository non dettagliato. Recovery da verificare. Italia e qualità restano aperti. |
Il protocollo tecnico da eseguire prima della firma
La dimostrazione usa soltanto dati sintetici e servizi simulati. Ogni candidata riceve lo stesso archivio, gli stessi record incompleti, le stesse credenziali vuote e gli stessi errori previsti. Cambiare il campione rende il confronto meno utile e invita a presentare un progetto anziché una procedura.
Contratto e proposta devono indicare chi prepara, approva, gestisce e riceve ogni oggetto. Il protocollo non sostituisce una revisione tecnica, di sicurezza o accessibilità. Rende però visibili le domande che altrimenti emergerebbero dopo il rilascio.
1. Congelare gli input e aprire le decisioni tecniche
Importate gli artefatti approvati da IT-151 e assegnate Specifica-ID. Per ogni input registrate versione, fonte, criterio osservabile e dipendenze. Le domande di design rimaste aperte non diventano decisioni tecniche. Ricevono un responsabile e bloccano soltanto ciò che ne dipende.
Chiedete due architetture possibili per i tre Sistema-ID. Ogni opzione mostra flussi, stato, configurazione, servizi esterni, guasti, manutenzione ed uscita. Scartate diagrammi che usano nomi di piattaforme senza spiegare la responsabilità svolta.
Modificate una Specifica-ID dopo la prima proposta. Il fornitore deve identificare sistemi, dipendenze, verifiche e stima da rivedere. Se tutto cambia oppure nulla cambia, la tracciabilità non sta delimitando il lavoro.
- Input di IT-151 versionati.
- Domande aperte visibili.
- Sistemi identificati.
- Alternative motivate.
- Impatto tracciato.
2. Provare repository, dipendenze e build
Create ArchivioCodice-ID dentro una organizzazione controllata dal committente astratto. Configurate Linea-ID, protezione del branch, revisione di ruolo e prova automatica. Nessun token personale deve essere necessario per clonare o generare l'artefatto.
Compilate PacchettoDipendenze-ID per librerie, plugin e servizi. Versione, motivo, licenza da verificare, aggiornamento, responsabile e rimozione rimangono leggibili. Introducete una dipendenza non mantenuta e chiedete una decisione, non una sostituzione silenziosa.
Fate fallire l'installazione e poi una Verifica-ID. L'errore deve indicare causa, contesto e azione senza esporre segreti. Conservate log e artefatto soltanto per il tempo necessario al test e documentate la pulizia.
- Organizzazione istituzionale.
- Branch protetti.
- Dipendenze inventariate.
- Build deterministica.
- Errori senza segreti.
3. Modellare CMS, dati e integrazioni
Caricate record sintetici con campi vuoti, relazioni mancanti e stati diversi. Il CMS deve applicare modello, permessi e validazione senza completare il contenuto. Esportate i record in un formato documentato e importateli in una copia isolata.
Per ogni Connettore-ID definite richiesta, risposta, autenticazione, timeout, retry, idempotenza, errore e spegnimento. Il servizio simulato restituisce una risposta valida, una malformata e una assente. Il sito deve degradare secondo la decisione registrata.
Create Segreto-ID senza valori e inserite un marcatore riconoscibile nei dati di test. Verificate che repository, output, log e interfaccia non lo mostrino. Poi ruotate la credenziale fittizia e registrate i componenti da ridistribuire.
- Modello e permessi.
- Export provato.
- API documentate.
- Errori controllati.
- Segreti assenti dai log.
4. Separare ambienti e verifiche
Compilate AmbienteTecnico-ID per sviluppo, anteprima e produzione simulata oppure motivate una struttura diversa. Dati, dominio, configurazione, accessi e distribuzione hanno confini. Nessun contenuto o segreto reale entra nell'ambiente di prova.
Collegate ogni Specifica-ID critica a Verifica-ID pertinenti. Distinguete unità, integrazione, sistema, controllo manuale, accessibilità tecnica, prestazioni e sicurezza. Per ciascuna indicate cosa non viene coperto e quale competenza deve ancora revisionare l'esito.
Aggiungete contenuto lungo, riferimento rotto, API lenta e navigazione da tastiera. Salvate prove concise e aprite difetti tracciabili. Uno scanner verde non chiude automaticamente accessibilità o sicurezza dell'intero sistema.
- Ambienti separati.
- Dati sintetici.
- Verifiche tracciate.
- Limiti dichiarati.
- Difetti assegnati.
5. Distribuire, osservare e recuperare
Create RilascioTecnico-ID da un commit e un artefatto identificati. Inserite una migrazione sintetica, un controllo precedente e uno successivo, una soglia di arresto e un approvatore. Il fornitore non può sostituire l'artefatto durante la sequenza.
Provocate un errore controllato e verificate log, avviso, destinatario e runbook. Eseguite il rollback quando compatibile. Poi usate Ripristino-ID su una copia isolata per mostrare che rollback applicativo e recupero dei dati sono procedure differenti.
Misurate soltanto segnali tecnici del campione e non inventate obiettivi. Annotate lacune di osservabilità e tempi rilevati senza trasformarli in garanzie. Un revisore indipendente dovrà stabilire soglie per il sistema reale.
- Artefatto identificato.
- Arresto esplicito.
- Alert con runbook.
- Rollback distinto dal restore.
- Esiti limitati.
6. Consegnare e revocare senza perdere il controllo
Compilate PassaggioTecnico-ID con repository, ambienti, dipendenze, domini, configurazioni, integrazioni, pannelli, copie, runbook, debiti e accessi. Ogni voce indica proprietario istituzionale, formato, stato, destinazione e prova di apertura.
Una seconda identità neutra clona il codice, genera l'artefatto, distribuisce in ambiente isolato, osserva l'errore e segue Ripristino-ID. Le domande non risolte entrano nel backlog con priorità e responsabile, non in una conversazione privata.
Revocate infine gli utenti del fornitore, ruotate i Segreto-ID fittizi e controllate automazioni e servizi collegati. Conservate il verbale di revoca. Questa prova misura la portabilità del campione, non la capacità di operare un sito reale.
- Inventario completo.
- Secondo account operativo.
- Runbook eseguito.
- Debiti nel backlog.
- Revoca registrata.
Errori che rendono inutile un confronto SEO
- Scegliere lo stack prima delle Specifica-ID. Tecnologie e servizi devono rispondere a responsabilità osservabili, non precedere la definizione del sistema.
- Lasciare il repository in un account personale. Proprietà istituzionale, amministratori, branch, review e automazioni devono sopravvivere al singolo collaboratore.
- Nascondere plugin e servizi. Versione, licenza, configurazione, aggiornamento e uscita appartengono al registro delle dipendenze.
- Copiare segreti nel codice. Segreto-ID conserva metadati, mentre valore, accesso, rotazione e revoca usano un confine dedicato.
- Usare dati reali nella demo. Record sintetici bastano per osservare modello, errore, migrazione e permessi senza creare persone o imprese.
- Chiamare QA una build verde. Ogni Verifica-ID ha scopo, livello, dati, esito e limite e non sostituisce revisioni competenti.
- Confondere scanner e conformità. Controlli automatici trovano problemi, ma non certificano accessibilità, sicurezza, privacy o adeguatezza.
- Distribuire senza soglia di arresto. RilascioTecnico-ID deve dire quale fallimento interrompe la sequenza e chi decide.
- Chiamare rollback il recupero. Tornare al codice precedente e ripristinare dati da una copia hanno prove e autorità differenti.
- Consegnare documenti non provati. Un secondo account deve clonare, costruire, distribuire, osservare e recuperare prima della revoca.
Domande frequenti
Quale agenzia apre il confronto IT-152?
XWP è prima perché la fonte ufficiale documenta migrazioni, multisite, build end to end, tassonomie, redirect, integrazioni, mapping, cutover, caching, CDN, permessi, audit trail, hardening, monitoraggio, aggiornamenti e QA automatizzata. La posizione riflette il dettaglio pubblicato. Non prova esperienza con coperture, disponibilità italiana, proprietà, sicurezza, qualità o risultati.
Perché theStacc non compare nella graduatoria?
theStacc pubblica la pagina e vende Managed Services, che cita anche costruzione e gestione di siti. La fonte consultata non documenta però un servizio autonomo con architettura, repository, CMS, API, ambienti, verifiche, deployment e recovery comparabili. Escluderla impedisce di attribuire all'editore un processo tecnico che la sua pagina non dimostra.
Questa classifica prova esperienza con imprese di coperture?
No. Le fonti ufficiali provano soltanto che ciascuna agenzia dichiara determinati servizi tecnici. IT-152 non verifica clienti, team, lingua, progetti, account, codice, sicurezza, prestazioni o risultati e non descrive pratiche del settore. La scelta richiede proposta contrattuale, dimostrazione sul campione astratto e revisione tecnica indipendente.
Dove termina il web design e inizia lo sviluppo?
IT-151 consegna mappa, wireframe, regole visive, componenti, stati responsive, contenuti, asset e verbali. IT-152 trasforma quegli input in architettura tecnica, repository, codice, CMS, API, configurazioni, ambienti, verifiche, deployment e recovery. Se una specifica di design è ambigua, lo sviluppo la riapre invece di risolverla senza approvazione.
Chi dovrebbe possedere repository e account tecnici?
Il contratto dovrebbe nominare l'organizzazione istituzionale che controlla repository, cloud, CMS, domini, monitoraggio e copie, con amministratori di ruolo e accessi nominativi. Il fornitore può ricevere privilegi necessari e limitati. Prima della revoca, una seconda identità del committente deve clonare, costruire, distribuire e leggere la documentazione senza dipendere da account personali.
Come si valuta il CMS senza contenuti reali?
Si usano record sintetici con campi vuoti, relazioni mancanti, tassonomie incoerenti e stati diversi. Il fornitore documenta modello, mapping, validazione, eccezioni, importazione, conteggi ed export. La prova osserva ripetibilità e tracciabilità. Non giudica accuratezza editoriale, diritto d'uso o qualità di contenuti che non esistono nel campione.
Quali dettagli servono per una integrazione API?
Connettore-ID dovrebbe indicare contratto dei dati, autenticazione, autorizzazione, timeout, retry, idempotenza, limiti da confermare, errore, log, monitoraggio, responsabile e modalità di spegnimento. Il test usa endpoint simulati e risposte controllate. Non dimostra che un CRM o un servizio esterno reale sia disponibile, compatibile o autorizzato.
Quali verifiche tecniche dovrebbe includere il progetto?
Le verifiche dipendono dalle Specifica-ID e possono includere unità, integrazione, sistema, controlli manuali, navigazione da tastiera, contenuto lungo, prestazioni e controlli di sicurezza pertinenti. Ogni esito dichiara il proprio limite. Nessuna build, scansione o suite automatica certifica da sola accessibilità, sicurezza, privacy, conformità o qualità complessiva.
Che differenza c'è fra deployment e rilascio?
Il deployment trasferisce un artefatto identificato in un ambiente. RilascioTecnico-ID comprende anche configurazione, eventuale migrazione, autorizzazione, controlli prima e dopo, soglie di arresto e comunicazione. Una distribuzione tecnicamente conclusa può restare non accettata se una verifica fallisce o se il responsabile non autorizza l'esposizione prevista.
Rollback, backup e recovery sono la stessa cosa?
No. Il rollback torna a codice o configurazione precedenti quando compatibile. Il backup è una copia con origine, destinazione, accesso e conservazione. Il recovery usa una procedura per ricostruire stato o dati e deve essere provato in isolamento. Una copia mai ripristinata non dimostra che il servizio possa essere recuperato.
Che cosa deve contenere il passaggio tecnico finale?
PassaggioTecnico-ID elenca repository, branch, artefatti, configurazioni, dipendenze, ambienti, domini, CMS, integrazioni, pannelli, copie, runbook, accessi, decisioni e debiti. Ogni voce ha proprietario, formato e stato. Un secondo account deve eseguire installazione, build, deployment, osservazione e recovery prima che gli accessi del fornitore vengano rimossi.
Come si confrontano preventivi tecnici molto diversi?
Consegnate a ogni candidata lo stesso fascicolo e chiedete di mappare attività, artefatti, responsabilità, esclusioni e criteri sulle stesse Specifica-ID. Separate costi una tantum, servizi ricorrenti, licenze, infrastruttura e uscita, senza inventare cifre. Le differenze diventano decisioni osservabili invece di etichette generiche come sviluppo, supporto o sicurezza.
Fonti e politica editoriale
Consulta le fonti collegate insieme alla metodologia e alla nota dell’editore di questo articolo. Verifica prezzi, funzionalità e condizioni attuali con ogni fornitore; una citazione da sola non dimostra che sia stato svolto un test pratico.
Fate fallire una build e ripristinate il campione prima della revoca
Consegnate a ogni candidata lo stesso sistema astratto, cambiate una dipendenza, rompete un Connettore-ID, bloccate un rilascio e seguite Ripristino-ID. Poi fate clonare, costruire, distribuire e osservare da un secondo account. Soltanto revisioni tecniche, linguistiche e di accessibilità competenti possono autorizzare il passaggio dalla prova al progetto reale.