Un sito può essere visibile e non essere trasferibile. Il problema emerge quando il repository appartiene a un account personale, la configurazione vive in una chat, lo staging non replica il rilascio, le dipendenze non sono inventariate o soltanto il fornitore conosce la procedura di rollback.
IT-146 confronta la disciplina di consegna tecnica, non siti reali. Il protocollo propone un repository vuoto, tre Service-ID, quattro Environment-ID, sei Dependency-ID, due Credential-ID neutri, una configurazione mancante, una release da interrompere e un export da aprire in un secondo account. Nessuna applicazione viene costruita.
Ogni passaggio deve lasciare una prova verificabile: requisito, decisione, commit, revisione, artefatto, log, approvazione o procedura. Un’attività dichiarata in una pagina ufficiale entra nella graduatoria come capacità pubblicata. Non diventa una prestazione osservata.
Il confine con IT-145 resta deliberato. Design consegna Page-ID, Component-ID, token, asset, contenuti, stati responsive e annotazioni. Sviluppo decide architettura tecnica, codice, CMS, API, ambienti, pipeline, QA e rilascio. Nessuno dei due workstream può approvare il lavoro dell’altro in silenzio.
theStacc pubblica IT-146, ma non è classificata. Le pagine ufficiali consultate non descrivono un servizio autonomo di sviluppo web confrontabile con le otto agenzie incluse, quindi attribuirle un’offerta tecnica sarebbe una fabbricazione. Nessuna agenzia ha pagato per apparire. Le descrizioni derivano esclusivamente dalle pagine ufficiali collegate, raggiungibili il 30 agosto 2026. Non abbiamo incaricato, intervistato o provato agenzie, team, repository, codice, CMS, API, account, ambienti, pipeline, test, release, backup, rollback, handoff o export. Non riportiamo prezzi. Devono ancora essere verificati entità contrattuale, disponibilità, copertura italiana, lingua, specialisti assegnati, subfornitori, stack proposto, accessi, proprietà dei file, procedure, revisioni, tempi, qualità e condizioni di uscita. Le fonti di prima parte sostengono soltanto il perimetro dichiarato dal rispettivo fornitore. Non dimostrano superiorità, idoneità, qualità, disponibilità o risultati. Il protocollo usa Repo-ID, Service-ID, Dependency-ID, Environment-ID, Release-ID e Credential-ID astratti, configurazioni vuote, dati sintetici privi di persone e identità neutre. Non contiene studi, dentisti, pazienti, siti, casi, prezzi, test eseguiti, posizionamenti, lead, ricavi, persone, revisori o proprietari reali o inventati. Non valuta testimonianze, recensioni o comunicazioni con pazienti. Non formula affermazioni cliniche, diagnostiche, terapeutiche, di sicurezza, legali, privacy, conformità o relative a esiti. IT-141 fino a IT-144 possiedono i workstream di marketing. IT-145 termina a ricerca progettuale, architettura informativa, UX/UI, componenti, responsive, contenuti e handoff di design. IT-146 inizia da requisiti tecnici, repository, implementazione, integrazioni, ambienti, QA, release, rollback ed export operativo. Mancano una revisione tecnica indipendente, una revisione competente del perimetro odontoiatrico, una revisione linguistica italiana e un responsabile di manutenzione. La pagina resta needs_human_review e non è autorizzata alla pubblicazione automatica.
La risposta breve
Imaginary Cloud apre la selezione perché documenta briefing, architettura, dipendenze esterne, repository, test automatizzati, staging, server di produzione, CI/CD e deployment. ScienceSoft e Netguru seguono per requisiti, scoping, sviluppo, qualità, lancio e manutenzione. Unified Infotech, OuterBox, Vention, Digital Silk e 10Clouds coprono altri processi, tutti da verificare con lo stesso protocollo astratto.
- Imaginary Cloud: organizzazioni che vogliono verificare requisiti, architettura, dipendenze, repository, test automatizzati, staging, produzione e deployment come passaggi distinti
- ScienceSoft: team che vogliono confrontare requirements engineering, scoping, controlli del ciclo, collaborazione, documentazione e trasferimento operativo
- Netguru: organizzazioni che vogliono verificare consultazione, scelta tecnologica, sviluppo, CMS, lancio e manutenzione in una sequenza pubblica
- Unified Infotech: team che vogliono confrontare discovery, pianificazione, front-end, back-end, integrazioni API, sprint, backlog, regressione e manutenzione
- OuterBox: organizzazioni che vogliono verificare architettura, modelli CMS, integrazioni, API, staging, controlli di rilascio e supporto
- Vention: team che vogliono confrontare raccolta requisiti, roadmap, tecnologia, front-end, back-end, integrazioni, QA lungo il ciclo e manutenzione
- Digital Silk: organizzazioni che vogliono verificare planning, information architecture, sviluppo responsive, CMS, integrazioni, lancio e supporto continuativo
- 10Clouds: team che vogliono verificare insight, discovery, introduzione, crescita, maturità, front-end, back-end e consulenza di prodotto
Il registro tecnico prima del primo commit
Il Requirement-ID descrive un comportamento, il relativo input, l’output atteso, le eccezioni e il criterio di accettazione. Il protocollo inserisce un requisito deliberatamente incompleto. L’agenzia deve bloccarlo, formulare domande e registrare la decisione, senza inventare dati, contenuti o funzionalità.
L’architettura collega Service-ID, Dependency-ID, archivio, interfaccia e responsabilità. La vista logica rimane separata dall’infrastruttura. Ogni scelta annota motivazione, alternativa, conseguenza e revisore astratto. Un diagramma decorativo privo di versioni e decisioni non basta per il passaggio al codice.
Il repository parte vuoto. Branch, convenzioni, dipendenze, file di configurazione d’esempio, documentazione e regole di revisione devono essere leggibili da un secondo operatore. Il protocollo non prescrive piattaforma, linguaggio o framework. Verifica soltanto che il lavoro non dipenda da una cartella privata.
Ogni Dependency-ID registra origine, versione, licenza da verificare, ambiente, servizio che la usa, responsabile astratto e procedura di aggiornamento. Nessuna libreria viene dichiarata sicura o conforme. Una dipendenza senza proprietario operativo resta un rischio aperto e non può sparire dal registro.
Il front-end riceve componenti e stati da IT-145, poi li traduce in struttura e comportamento. Il back-end riceve contratti di servizio e dati sintetici. Il protocollo vieta di dedurre API, archivi o regole applicative da un mockup. Ogni scarto dal design torna al registro delle decisioni.
Il CMS viene valutato su ruoli astratti, tipi di contenuto, campi obbligatori, anteprima, versioni, migrazione ed export. Non si usa contenuto reale. Una modifica editoriale deve propagarsi senza alterare il modello dati o richiedere un intervento non documentato del fornitore.
Le integrazioni usano endpoint fittizi e payload sintetici. Ogni Integration-ID conserva contratto, autenticazione astratta, timeout, errore, retry, dipendenza e proprietario. Nessun servizio esterno viene collegato. La prova controlla soltanto se il progetto sa distinguere interfaccia, configurazione e comportamento di errore.
I quattro Environment-ID rappresentano sviluppo, verifica, preproduzione e produzione senza ospitare un sito. Configurazioni e credenziali sono segnaposto neutri, mai valori reali. Le differenze devono essere intenzionali, documentate e riproducibili. Una variabile conosciuta soltanto a voce rende incompleto l’handoff.
La pipeline proposta collega commit, controllo, artefatto, ambiente e Release-ID. IT-146 non presume uno strumento specifico. Chiede che lo stesso artefatto possa avanzare, essere rifiutato o essere ritirato con una cronologia visibile, senza ricostruzioni manuali non dichiarate.
Il piano QA separa controlli unitari, integrazione, interfaccia, contenuto, responsive, accessibilità nel processo e rilascio. Non dichiara copertura, conformità o superamento. Ogni controllo deve avere oggetto, ambiente, prerequisito, esito ammesso, evidenza richiesta e responsabile astratto.
L’accessibilità entra come requisito verificabile, non come certificazione. Component-ID, struttura, nomi, ordine, focus previsto, alternative ed errori provenienti da IT-145 diventano controlli tecnici. Qualunque affermazione di conformità richiederebbe competenze e prove fuori dal protocollo editoriale.
Una release si riferisce a commit, artefatto, configurazione, ambiente, approvazione e procedura di ritorno. Il protocollo propone una condizione di stop prima del rilascio. L’agenzia deve mostrare dove il flusso si ferma e quali registri vengono aggiornati, senza eseguire una pubblicazione reale.
Il rollback non è una promessa generica. Deve nominare trigger, versione di ritorno, dati interessati, ordine, responsabilità e prova successiva. IT-146 non esegue backup o ripristino. Verifica se la proposta distingue il ritorno del codice dal recupero di dati e configurazioni.
Credential-ID e account neutri separano organizzazione, fornitore e automazione. Il protocollo richiede inventario, ruolo, custodia, sostituzione, revoca e dipendenza, ma non inserisce segreti. La prova di uscita rimuove soltanto identità fittizie dopo aver confermato l’accesso del secondo account.
Il runbook descrive avvio, configurazione, controllo, rilascio, osservazione, stop e recupero con riferimenti agli artefatti. Una sequenza che funziona soltanto sul computer di chi l’ha scritta non è una consegna. Ogni comando resta illustrativo finché un revisore tecnico non lo esegue in un ambiente autorizzato.
L’handoff riunisce requisiti, decisioni, architettura, repository, dipendenze, CMS, contratti API, ambienti, pipeline, QA, release, backlog e runbook. Le domande aperte restano aperte. Un documento finale non deve cancellare eccezioni, debiti o passaggi ancora manuali.
L’export viene aperto prima della revoca. Repository, documentazione, artefatti ammessi, configurazioni d’esempio, registri e procedure devono essere leggibili da un secondo account. Link scaduti, file proprietari non trasferiti e dipendenze personali diventano elementi bloccanti, non note da risolvere dopo il contratto.
Prove di adeguatezza al settore da richiedere
- I requisiti incompleti vengono bloccati e trasformati in domande versionate.
- Architettura, dipendenze e contratti collegano decisioni e responsabilità.
- Repository, branch, review e configurazioni d’esempio sono trasferibili.
- CMS e API usano contenuti ed endpoint sintetici senza sistemi reali.
- Ambienti e pipeline distinguono configurazione, artefatto e promozione.
- QA registra oggetto, prerequisito, ambiente, evidenza ed esito ammesso.
- Release, rollback e recupero hanno procedure separate e versionate.
- Handoff ed export aprono in un secondo account prima della revoca.
Come abbiamo valutato i fornitori
La graduatoria misura la profondità del processo tecnico visibile sulla singola pagina ufficiale. Imaginary Cloud è prima perché documenta briefing, architettura di alto livello, dipendenze esterne, repository, framework di test automatizzati, staging, server di produzione, CI/CD, deploy hook e prima release.
ScienceSoft segue per requirements engineering, scoping, controlli di qualità lungo il ciclo di sviluppo, collaborazione e trasferimento della conoscenza, oltre a sviluppo, integrazione, testing e manutenzione. Netguru pubblica una sequenza da consultazione e scelta tecnologica fino a sviluppo, lancio e supporto, con CMS e sviluppo continuativo.
Unified Infotech descrive discovery, pianificazione, sviluppo front-end e back-end, integrazioni API, sprint, controllo manuale, regressione, backlog e manutenzione. OuterBox espone architettura, CMS, integrazioni, controlli di staging, release QA e supporto dopo il lancio.
Vention documenta requisiti, roadmap, tecnologia, front-end, back-end, integrazioni, QA lungo il ciclo e manutenzione. Digital Silk presenta strategia, architettura informativa, sviluppo responsive, lancio, supporto, CMS e integrazioni. 10Clouds descrive un ciclo di prodotto e servizi front-end, back-end e consulenza, ma la pagina scelta espone meno dettagli su handoff ed export.
Nessuna posizione deriva da test, prezzo, recensione, caso, qualità osservata o disponibilità. Ogni agenzia riceverebbe lo stesso protocollo astratto. theStacc resta fuori perché non possiede una pagina ufficiale che documenti un servizio comparabile.
| Criterio | Peso | Che cosa ha contato |
|---|---|---|
| Requisiti e architettura | Priorità alta | Scopo, dipendenze, interfacce, alternative e decisioni devono precedere l’implementazione. |
| Codice, CMS e integrazioni | Priorità alta | Repository, modelli, API, configurazioni e dipendenze restano leggibili e trasferibili. |
| Ambienti e pipeline | Priorità alta | Artefatti e configurazioni avanzano fra ambienti con controlli e cronologia espliciti. |
| QA e accessibilità nel processo | Priorità alta | Controlli e prove sono tracciabili senza trasformarsi in garanzie o certificazioni. |
| Release, rollback e recovery | Priorità alta | Stop, rilascio, ritorno e recupero hanno trigger, responsabilità e verifiche distinti. |
| Credenziali, handoff ed export | Priorità alta | Account, repository, runbook e backlog restano accessibili dopo l’uscita del fornitore. |
Ogni fornitore doveva soddisfare gli stessi requisiti minimi prima che la sua posizione venisse presa in considerazione.
- La fonte doveva essere una pagina ufficiale di servizio raggiungibile il 30 agosto 2026.
- La pagina doveva descrivere sviluppo web o web application development come offerta esplicita.
- Il perimetro doveva coprire almeno requisiti, architettura, front-end, back-end, CMS, integrazioni, QA, rilascio o manutenzione.
- Design, marketing, hosting, sicurezza, privacy e conformità non sono stati dedotti dal termine sviluppo.
- Prezzi, team, copertura italiana, proprietà, risultati e tempi non sono stati presunti.
- theStacc è esclusa perché manca una pagina ufficiale di sviluppo web 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.
Imaginary Cloud
Punti di forza documentati
- Briefing e requisiti documentati.
- Architettura e dipendenze esterne sono esplicite.
- Repository, test framework e staging compaiono.
- CI/CD e deployment sono descritti.
Limiti da verificare
- Proprietà del repository da confermare.
- Recovery operativo non provato.
- Italia e team non verificati.
- Export completo da dimostrare.
Imaginary Cloud apre la selezione perché la pagina ufficiale descrive briefing, high-level architecture, dipendenze da terze parti, product backlog, sprint backlog, code repository, automated test framework, staging environment, production servers, continuous integration, continuous deployment e prima versione distribuita. La fonte non prova Italia, odontoiatria, team, proprietà, export, qualità o risultati.
Consegnate Requirement-ID incompleti e Dependency-ID astratti. Il briefing deve conservare obiettivi, vincoli e domande. L’architettura registra dipendenze esterne senza collegare servizi reali o dedurre una tecnologia dai mockup.
Aprite un Repo-ID vuoto con configurazioni d’esempio. Chiedete backlog, code repository, framework di controllo automatizzato e ambienti separati. Ogni voce conserva responsabile astratto, versione e relazione con la pipeline.
Interrompete una Release-ID prima della promozione. CI/CD, staging, server finali e deploy hook devono mostrare dove il flusso si arresta e come riparte. Nessuna release reale viene eseguita.
Richiedete accessi organizzativi, inventario, runbook, backlog, artefatti ammessi, procedure di ritorno ed export. Il primo posto riflette dettaglio tecnico pubblicato, non un’esecuzione osservata.
Fonti sui fornitori: Imaginary Cloud, servizio web development ufficiale, consultato il 30.08.2026
ScienceSoft
Punti di forza documentati
- Requirements engineering e scoping espliciti.
- Cambio di scopo documentato.
- Controlli lungo il ciclo pubblicati.
- Knowledge transfer e documentazione sono visibili.
Limiti da verificare
- Garanzie promozionali non adottate.
- Repository ed export da confermare.
- Italia e team non provati.
- Recovery operativo richiede evidenza.
ScienceSoft è seconda perché la pagina ufficiale documenta requirements engineering, scoping, scope-change management, controlli di qualità per stadio SDLC, collaborazione, knowledge management e knowledge transfer. Presenta inoltre sviluppo front-end e back-end, integrazione, testing e manutenzione. IT-146 non ripete garanzie promozionali presenti sulla fonte e non attribuisce sicurezza o conformità. Italia, odontoiatria, team, proprietà, export, qualità e risultati non sono provati.
Fornite un requisito ambiguo e una richiesta di modifica. Scoping e gestione del cambio devono mostrare effetto su architettura, backlog, ambiente, QA e release. Nessun requisito viene completato per intuizione.
Chiedete una matrice SDLC con decisione, controllo, evidenza e responsabile astratto per ciascuno stadio. Le etichette di qualità pubblicate non sostituiscono criteri verificabili nel contratto.
Rimuovete una persona neutra dal team proposto. Knowledge management e transfer devono lasciare documenti, decisioni, dipendenze e runbook comprensibili al sostituto, senza accesso a informazioni reali.
Richiedete repository, configurazioni, ambienti, procedure di rilascio e ritorno, backlog ed export. Il secondo posto deriva dalla governance descritta, non da qualità o puntualità osservate.
Fonti sui fornitori: ScienceSoft, servizi web development ufficiali, consultati il 30.08.2026
Netguru
Punti di forza documentati
- Consultazione e scelta tecnologica sono esplicite.
- Sviluppo e lancio formano una sequenza.
- CMS è un servizio dichiarato.
- Supporto e sviluppo continuativo compaiono.
Limiti da verificare
- QA incluso da confermare.
- DevOps non attribuito automaticamente.
- Repository e recovery non provati.
- Italia ed export restano aperti.
Netguru figura terza perché la pagina ufficiale espone una sequenza che parte dalla consultazione dell’idea, passa per scelta della tecnologia, design e sviluppo e arriva al mercato con supporto e manutenzione. La stessa pagina elenca siti, e-commerce, web application, CMS e ongoing web development. Le capacità QA, DevOps e cloud compaiono nel portafoglio, ma IT-146 non le trasforma in attività incluse. Italia, odontoiatria, team, proprietà, export, qualità e risultati restano non provati.
Consegnate requisiti e dipendenze senza stack assegnato. La consultazione deve separare bisogno, vincolo e ipotesi. La scelta tecnologica registra alternative e conseguenze prima che il team apra il repository.
Create un Content-Type astratto e una Integration-ID fittizia. CMS e codice devono distinguere modello, interfaccia, configurazione ed errore, senza popolare contenuti o collegare sistemi esterni.
Bloccate una release prima dell’ambiente finale. Il passaggio verso il mercato e il supporto successivo devono chiarire approvazione, artefatto, responsabilità, backlog e procedura di ritorno.
Richiedete account, repository, configurazioni, pipeline, runbook, inventario ed export. Il terzo posto descrive ampiezza pubblicata; QA, DevOps e ambienti effettivi vanno confermati nella proposta.
Fonti sui fornitori: Netguru, servizi web development ufficiali, consultati il 30.08.2026
Unified Infotech
Punti di forza documentati
- Discovery e planning documentati.
- Front-end, back-end e API sono visibili.
- Milestone, sprint e backlog compaiono.
- Controlli manuali e regressione sono espliciti.
Limiti da verificare
- Design escluso dal confronto.
- Ambienti da confermare.
- Repository e proprietà non provati.
- Italia ed export restano aperti.
Unified Infotech è quarta perché la pagina ufficiale descrive discovery workshop, predictive planning, IA e UX/UI, sviluppo front-end collegato al back-end, requisiti di API integration, struttura del codice, milestone e sprint, controlli manuali, bug report, aggiornamento del backlog, demo, approvazione e regression testing. Pubblica inoltre supporto e manutenzione. IT-146 esclude design e affermazioni promozionali. Italia, odontoiatria, team, proprietà, export, qualità e risultati non sono dimostrati.
Consegnate Requirement-ID con una lacuna e una API fittizia. Discovery e planning devono aprire domande, dipendenze e milestone. IA e UI restano input da IT-145, non risultati del workstream tecnico.
Create due sprint astratti e una modifica di contratto. Front-end, back-end e API devono aggiornare backlog, decisione, review ed evidenza richiesta. Nessun endpoint o dato reale viene usato.
Inserite una regressione teorica dopo l’approvazione del primo sprint. Il piano deve riaprire controlli dipendenti e collegare bug, backlog e nuova versione senza affermare che un test sia stato eseguito.
Richiedete repository, ambienti, configurazioni, release, rollback, runbook, accessi ed export. La quarta posizione deriva dal dettaglio del processo pubblicato, non da una consegna provata.
Fonti sui fornitori: Unified Infotech, servizi web development ufficiali, consultati il 30.08.2026
OuterBox
Punti di forza documentati
- Architettura prima dei template.
- CMS implementation è esplicita.
- Integrazioni e API sono documentate.
- Staging, release QA e supporto compaiono.
Limiti da verificare
- SEO e design restano fuori.
- Nessuna garanzia attribuita.
- Repository e recovery non provati.
- Italia ed export da verificare.
OuterBox è quinta perché la pagina ufficiale documenta sviluppo indipendente dalla piattaforma, architettura prima dei template, CMS implementation, integrations and APIs, controlli di staging, release QA e supporto dopo il lancio. La fonte tratta anche UX, SEO, performance, hosting e sicurezza, che IT-146 non attribuisce come garanzie o risultati. Non prova Italia, odontoiatria, team, proprietà effettiva, repository, export, qualità o risultati.
Fornite un’architettura logica e un Content-Type vuoto. Il team deve collegare template, CMS, dipendenze e criteri senza estendere il design o inventare contenuti per completare la struttura.
Create una Integration-ID con endpoint fittizio e un errore ammesso. API e CMS devono separare contratto, configurazione, comportamento di errore e responsabilità, senza connettere CRM, ERP o altri sistemi reali.
Interrompete la proposta durante lo staging. I controlli pre-release e la release QA devono mostrare oggetto, ambiente, evidenza, approvazione e ritorno. Nessun lancio viene effettuato.
Richiedete repository, account, configurazioni, runbook, backlog e export. Il quinto posto riflette il processo visibile, mentre proprietà, ambienti e recovery devono essere provati contrattualmente.
Fonti sui fornitori: OuterBox, servizi web development ufficiali, consultati il 30.08.2026
Vention
Punti di forza documentati
- Requisiti e roadmap sono documentati.
- Front-end e back-end sono espliciti.
- Integrazioni e QA compaiono.
- Supporto e manutenzione sono pubblicati.
Limiti da verificare
- UI/UX esclusa.
- Ambienti e pipeline da confermare.
- Repository e recovery non provati.
- Italia ed export restano aperti.
Vention è sesta perché la pagina ufficiale descrive gathering requirements, roadmap, scelta tecnologica, timeline, UI/UX, development, testing, support and maintenance. I servizi elencano front-end, back-end, integration services, QA and testing, modernization, CMS ed e-commerce. IT-146 non adotta affermazioni promozionali su performance, sicurezza o risultati e rinvia UI/UX a IT-145. Italia, odontoiatria, team, repository, proprietà, export, qualità e risultati non sono provati.
Consegnate requisiti con una dipendenza non risolta. Roadmap, tecnologia e timeline devono conservarla come domanda o blocco. UI/UX arriva da IT-145 e non autorizza decisioni di architettura implicite.
Create un contratto sintetico fra front-end e back-end. Integration-ID, errore, timeout e configurazione devono essere versionati. Nessun servizio, CMS o archivio reale viene collegato.
Modificate un requisito dopo l’avvio astratto. QA lungo il ciclo deve riaprire controlli dipendenti e aggiornare backlog e decisioni. Il protocollo non attribuisce copertura o superamento.
Richiedete repository, ambienti, pipeline, release, maintenance, runbook ed export. La sesta posizione riflette le fasi pubblicate, non la qualità o la continuità del team.
Fonti sui fornitori: Vention, servizi web application development ufficiali, consultati il 30.08.2026
Digital Silk
Punti di forza documentati
- Planning e IA sono stadi pubblici.
- Responsive development è esplicito.
- CMS e integrazioni sono trattati.
- Launch e ongoing support compaiono.
Limiti da verificare
- Design e marketing esclusi.
- Titolarità non dedotta da project ownership.
- Repository e recovery non provati.
- Italia ed export da verificare.
Digital Silk è settima perché la pagina ufficiale presenta un processo con web strategy, planning, information architecture, creative design, responsive development, launch e ongoing support services. Le FAQ ufficiali trattano stack, integrazioni di terze parti e scelta del CMS. IT-146 esclude strategia di marketing e design, non ripete risultati di casi o recensioni e non interpreta project ownership come proprietà legale dei file. Italia, odontoiatria, team, repository, export, qualità e risultati non sono provati.
Fornite Requirement-ID e decisioni di design già approvate. Planning e information architecture devono tradurli in dipendenze tecniche senza riaprire messaggi, estetica o marketing.
Create un Content-Type e una Integration-ID fittizi. CMS e collegamenti di terze parti devono avere contratto, configurazione d’esempio, errore e proprietario astratto, senza account reali.
Bloccate una release prima del lancio. Responsive development, launch e support devono distinguere controllo, approvazione, procedura di ritorno e backlog successivo.
Richiedete repository, ambienti, account, runbook, cronologia ed export. Il settimo posto deriva dalla sequenza pubblicata; la dicitura project ownership non viene usata come prova di titolarità.
Fonti sui fornitori: Digital Silk, servizi web development ufficiali, consultati il 30.08.2026
10Clouds
Punti di forza documentati
- Ciclo di prodotto documentato.
- Insight e discovery sono visibili.
- Front-end e back-end sono espliciti.
- Product consulting compare.
Limiti da verificare
- CMS da confermare.
- QA e ambienti poco dettagliati.
- Repository e recovery non documentati.
- Italia ed export restano aperti.
10Clouds è ottava perché la pagina ufficiale descrive un Product Delivery Lifecycle articolato in insight, discovery, introduction, growth e maturity. Elenca inoltre frontend development, backend development, product consulting e team augmentation, con tecnologie web e cloud. La pagina scelta espone meno dettaglio verificabile su CMS, controlli QA, ambienti, repository, release, recovery ed export. Non prova Italia, odontoiatria, team assegnato, proprietà, qualità o risultati.
Consegnate un problema astratto e requisiti incompleti. Insight e discovery devono produrre domande, decisioni e un backlog, senza inventare mercato, persone o funzionalità.
Create un contratto sintetico fra front-end e back-end. Product consulting deve registrare alternative e conseguenze, mentre team augmentation non viene interpretata come disponibilità o composizione effettiva.
Chiedete di mappare introduction, growth e maturity su ambienti, QA, release e manutenzione. La pagina ufficiale non basta per presumere inclusione, quindi ogni passaggio resta da confermare nella proposta.
Richiedete CMS, repository, pipeline, runbook, recovery, handoff ed export. L’ottavo posto riflette i dettagli mancanti sulla pagina scelta, non un giudizio sulla capacità del fornitore.
Fonti sui fornitori: 10Clouds, servizio web development 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 processi sullo stesso protocollo astratto
La tabella collega soltanto il perimetro visibile sulle pagine ufficiali alle prove da chiedere. Non attribuisce disponibilità, qualità, prezzi, team, proprietà, sicurezza, conformità, copertura italiana, siti o risultati.
| Fornitore | Modello di erogazione | Ambito documentato | Ideale per | Limite principale |
|---|---|---|---|---|
| Imaginary Cloud | Architettura e CI/CD | briefing, architecture, repo, test framework, staging, deployment | pipeline e ambienti | export da provare |
| ScienceSoft | Governance SDLC | requirements, scoping, quality controls, knowledge transfer | scopo e documenti | recovery da provare |
| Netguru | Idea al mercato | consult, technology, develop, launch, CMS, ongoing | sequenza end-to-end | DevOps da confermare |
| Unified Infotech | Sprint e regressione | discovery, code, API, sprint, backlog, regression | review per sprint | ambienti aperti |
| OuterBox | CMS e release QA | architecture, CMS, APIs, staging, release QA, support | modelli e integrazioni | repository non provato |
| Vention | Full-stack e QA | requirements, roadmap, frontend, backend, integration, testing | contratti tecnici | pipeline da confermare |
| Digital Silk | Planning e lancio | planning, IA, responsive development, CMS, integrations, launch | passaggio al supporto | titolarità da provare |
| 10Clouds | Ciclo di prodotto | insight, discovery, introduction, growth, maturity, frontend, backend | fasi di prodotto | QA poco dettagliato |
Il protocollo tecnico prima di affidare un progetto
Il pacchetto proposto contiene dodici Requirement-ID, tre Service-ID, sei Dependency-ID, quattro Environment-ID, due Credential-ID neutri, un Repo-ID vuoto, una configurazione incompleta, una release da fermare e un export da aprire altrove. Non contiene codice, contenuti, sistemi, persone o dati reali.
Ogni fase registra input, versione, decisione, dipendenza, responsabile astratto, criterio ed evidenza attesa. Il protocollo non assegna punti a un linguaggio o a una piattaforma. Valuta se un’organizzazione potrebbe capire, controllare e trasferire la consegna senza dipendere dalla memoria del fornitore.
1. Congelare requisiti e decisioni
Assegnate Requirement-ID a ogni comportamento. Registrate input, output, eccezione, dipendenza e criterio. Lasciate un requisito incompleto e verificate che diventi una domanda, non una funzione inventata.
Create un decision log con alternativa, conseguenza e revisore astratto. Ogni scelta di stack, CMS o integrazione deve riferirsi a un requisito, non a una preferenza priva di contesto.
Congelate la baseline. Una modifica successiva riapre architettura, implementazione, QA e release interessati. La versione precedente rimane consultabile.
- Dodici Requirement-ID.
- Lacuna visibile.
- Decision log.
- Dipendenze collegate.
- Baseline congelata.
- Cambio versionato.
2. Preparare repository e ambienti
Aprite un Repo-ID vuoto sotto un account organizzativo di prova. Definite branch, review, dipendenze, documentazione e configurazioni d’esempio senza segreti o codice reale.
Create quattro Environment-ID con scopo e differenze dichiarate. Ogni variabile conserva nome, ambiente, proprietario astratto e modalità di sostituzione, mai un valore autentico.
Fate aprire repository e documentazione a un secondo account neutro. Un percorso accessibile soltanto alla prima identità blocca il passaggio successivo.
- Repo-ID organizzativo.
- Branch dichiarati.
- Review prevista.
- Quattro ambienti.
- Nessun segreto.
- Secondo account.
3. Collegare codice, CMS e integrazioni
Collegate Service-ID e Component-ID tramite contratti sintetici. Front-end e back-end devono condividere versione, errore, dipendenza e criterio senza dedurre logica dal visual.
Create tipi CMS vuoti con campi, ruoli e versioni. Inserite una modifica incompatibile e chiedete migrazione, controllo e procedura di ritorno, senza pubblicare contenuti.
Usate Integration-ID fittizi con timeout ed errore ammesso. Nessun CRM, pagamento, archivio o sistema esterno viene connesso.
- Tre Service-ID.
- Contratti versionati.
- CMS vuoto.
- Migrazione descritta.
- Sei Dependency-ID.
- Endpoint fittizi.
4. Fermare una release e descrivere il ritorno
Collegate commit, artefatto, configurazione, ambiente e Release-ID. Inserite una condizione di stop. La pipeline proposta deve registrare il blocco e impedire la promozione.
Separate rollback del codice, recupero della configurazione e ripristino dei dati. Ogni procedura dichiara trigger, ordine, responsabilità e controllo successivo senza eseguirli.
Aggiornate backlog, runbook e decisioni dopo lo stop. Una procedura utile conserva anche ciò che non è stato verificato.
- Release-ID.
- Artefatto identificato.
- Stop registrato.
- Rollback distinto.
- Recovery distinto.
- Backlog aggiornato.
5. Aprire l’handoff prima della revoca
Esportate requisiti, decisioni, architettura, repository, dipendenze, contratti, CMS, configurazioni d’esempio, pipeline, QA, release, backlog e runbook.
Aprite ogni elemento in un secondo account. Il nuovo operatore deve riconoscere versione approvata, ambiente, elementi bloccati, procedure e prossime azioni senza contattare il precedente.
Revocate le identità neutre soltanto dopo la prova di accesso. File mancanti, link personali o procedure non riproducibili restano blocchi contrattuali.
- Repository leggibile.
- Runbook presente.
- Backlog esportato.
- Secondo account aperto.
- Identità revocate.
- Blocchi registrati.
Errori che rendono inutile un confronto SEO
- Scegliere lo stack prima dei requisiti. Tecnologia e architettura devono rispondere a vincoli documentati, non sostituirli.
- Tenere il repository in un account personale. Accesso, review, cronologia ed export devono sopravvivere alla singola identità.
- Mescolare configurazione e codice. Ambienti e valori cambiano senza creare versioni divergenti del progetto.
- Collegare sistemi reali nel pilota. Contratti, errori e dipendenze si provano con endpoint e dati sintetici.
- Chiamare staging una cartella separata. Un ambiente richiede scopo, configurazione, artefatto, accesso e procedura riconoscibili.
- Trattare QA come una fase finale. Requisiti, contratti, componenti e release devono portare controlli lungo il ciclo.
- Dichiarare accessibilità dal codice non verificato. IT-146 traduce requisiti in controlli, senza attribuire conformità.
- Confondere rollback e recovery. Ritorno del codice, configurazioni e dati richiedono procedure e responsabilità diverse.
- Consegnare un link invece del repository. Codice, dipendenze, documentazione e cronologia devono restare trasferibili.
- Revocare prima dell’export. Il secondo account deve aprire artefatti e procedure prima di rimuovere gli accessi.
Domande frequenti
Quali agenzie di sviluppo web dovrebbero valutare per primi i dentisti?
Imaginary Cloud apre questa selezione per il dettaglio pubblico su requisiti, architettura, repository, test automatizzati, staging, produzione, CI/CD e deployment. ScienceSoft e Netguru seguono per scoping, controlli del ciclo, sviluppo, lancio e manutenzione. L’ordine misura documentazione ufficiale, non qualità. Ogni agenzia deve comunque superare lo stesso protocollo astratto e l’export.
Che cosa comprende lo sviluppo web in IT-146?
IT-146 comprende requisiti tecnici, architettura, repository, front-end, back-end, CMS, integrazioni, dipendenze, ambienti, pipeline, QA, accessibilità nel processo, release, rollback, recovery, credenziali, runbook, handoff ed export. Strategia, contenuti, UX/UI e componenti visivi appartengono a IT-145 o ai workstream di marketing. Hosting, sicurezza, privacy e conformità non vengono presunti.
Come si confrontano agenzie senza costruire un sito?
Usate Requirement-ID, Service-ID, Dependency-ID, Environment-ID, Release-ID e Credential-ID astratti, un repository vuoto, configurazioni d’esempio, endpoint fittizi e dati sintetici. Chiedete procedure ed evidenze attese senza eseguire sviluppo o rilascio. Il confronto riguarda tracciabilità, trasferibilità e gestione delle eccezioni, non estetica, prestazioni o risultati reali.
Che cosa deve contenere un requisito tecnico?
Un requisito tecnico dovrebbe indicare comportamento, input, output, eccezioni, dipendenze, ambiente, criterio di accettazione, versione e responsabile astratto. Se manca un elemento, il team apre una domanda e registra l’impatto. Non completa il requisito in base a un mockup o a un testo plausibile. Ogni modifica successiva riapre i controlli dipendenti.
Come si valuta l’architettura proposta?
Collegate ogni Service-ID a requisiti, dipendenze, interfacce, dati sintetici e decisioni. Chiedete alternative e conseguenze, non soltanto un diagramma finale. Modificate una dipendenza e verificate quali servizi, ambienti, controlli e procedure devono essere riesaminati. Nessuna architettura viene dichiarata migliore, sicura o conforme senza una revisione tecnica indipendente.
Chi dovrebbe controllare il repository?
L’organizzazione dovrebbe avere un account istituzionale con accesso al repository, alla cronologia, alle review, alla documentazione e alle configurazioni d’esempio. Il fornitore usa identità revocabili. Il protocollo apre il progetto in un secondo account prima dell’uscita. Proprietà legale, licenze e condizioni di trasferimento devono essere definite nel contratto e verificate da competenze appropriate.
Che cosa bisogna verificare in un CMS?
Verificate tipi di contenuto, campi obbligatori, ruoli astratti, anteprima, versioni, migrazione, dipendenze ed export. Inserite una modifica incompatibile e chiedete come cambia il modello senza perdere la versione precedente. Usate contenuti vuoti o sintetici. Un editor semplice non dimostra che configurazioni, plugin, modelli e dati siano trasferibili.
Come si controlla un’integrazione senza collegare sistemi reali?
Definite una Integration-ID con contratto, payload sintetico, autenticazione astratta, timeout, errore, retry, dipendenza e proprietario. Usate un endpoint fittizio e nessun account reale. Modificate poi una versione del contratto e chiedete come vengono aggiornati codice, ambiente, QA, release e runbook. Il test effettivo richiede un contesto autorizzato separato.
Quali ambienti dovrebbe descrivere la proposta?
La proposta dovrebbe nominare almeno gli ambienti necessari al proprio processo e spiegare scopo, accesso, configurazione, artefatto, dati ammessi, promozione e ritorno. IT-146 usa quattro Environment-ID astratti, senza prescrivere infrastruttura. Le differenze devono essere intenzionali e versionate. Un ambiente conosciuto soltanto a voce rende incompleti QA, rilascio e handoff.
Che cosa deve contenere il piano QA?
Il piano QA collega ogni controllo a requisito, oggetto, prerequisito, ambiente, evidenza attesa, esito ammesso e responsabile astratto. Distingue unità, integrazione, interfaccia, contenuto, responsive, accessibilità nel processo e release quando applicabili. IT-146 non attribuisce copertura, conformità o superamento. Le prove reali spettano a un team autorizzato e competente.
Come si tratta l’accessibilità nello sviluppo?
Trasformate Component-ID, struttura, nomi, ordine, focus previsto, alternative, stati ed errori ricevuti da IT-145 in requisiti e controlli tecnici. Registrate ambiente, evidenza e domande aperte. Non dichiarate conformità dal mockup, dal codice o dalla pagina commerciale del fornitore. Una valutazione completa richiede implementazione, strumenti, verifica competente e perimetro definito.
Che differenza c’è tra release e deployment?
Nel protocollo, il deployment sposta un artefatto verso un ambiente; la release autorizza una versione per l’uso previsto. I due passaggi possono coincidere oppure restare separati, ma la proposta deve dichiararlo. Ogni Release-ID collega commit, artefatto, configurazione, approvazione, ambiente, stop e ritorno senza presumere uno strumento specifico.
Che differenza c’è tra rollback e recovery?
Il rollback riporta codice o configurazione a una versione precedente. Il recovery ricostruisce uno stato operativo dopo un’interruzione e può coinvolgere dati, dipendenze e procedure diverse. IT-146 non esegue nessuno dei due. Chiede trigger, ordine, responsabilità, prerequisiti ed evidenza successiva, così una parola generica non nasconde passaggi incompatibili.
Che cosa deve contenere il runbook?
Il runbook dovrebbe descrivere avvio, configurazione, dipendenze, controllo, rilascio, osservazione, stop, rollback, recovery e contatti di ruolo, con riferimenti a repository e artefatti. Non deve contenere segreti. Un secondo operatore dovrebbe capire versione approvata, ambiente, elementi bloccati e prossime azioni. L’esecuzione effettiva richiede autorizzazione e revisione tecnica.
Che cosa separa IT-146 da IT-145?
IT-145 definisce architettura informativa, wireframe, UX/UI, componenti, token, contenuti, asset, responsive e annotazioni di design. IT-146 riceve quel pacchetto e decide architettura tecnica, repository, codice, CMS, API, ambienti, QA, release e rollback. Un prototipo non prova l’implementazione, mentre il codice non può modificare il design senza una decisione versionata.
Perché IT-146 rimane in revisione umana?
Le fonti ufficiali documentano servizi, ma nessuna agenzia, team, repository, ambiente, pipeline, test, release, rollback, recovery, handoff o export è stato provato. Domanda esatta e risultati di ricerca italiani non sono verificati. Mancano revisione tecnica indipendente, revisione competente del perimetro odontoiatrico, revisione linguistica e responsabile di manutenzione. Lo stato resta needs_human_review.
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.
- [01]Imaginary Cloud, servizio web development ufficiale
- [02]ScienceSoft, servizi web development ufficiali
- [03]Netguru, servizi web development ufficiali
- [04]Unified Infotech, servizi web development ufficiali
- [05]OuterBox, servizi web development ufficiali
- [06]Vention, servizi web application development ufficiali
- [07]Digital Silk, servizi web development ufficiali
- [08]10Clouds, servizio web development ufficiale
Provate repository e runbook prima di revocare gli accessi
Una proposta tecnica utile blocca un requisito incompleto, collega architettura e dipendenze, separa configurazioni e codice, usa endpoint sintetici, ferma una release, distingue rollback e recovery, apre repository e runbook in un secondo account e conserva i debiti nel backlog. IT-146 richiede ancora revisione tecnica, revisione linguistica italiana, controllo competente del perimetro odontoiatrico e un responsabile di manutenzione prima della pubblicazione.