7 segnali che l'agenzia di sviluppo sta per deluderti

Sesta settimana di sviluppo, un founder chiede un link. L'agenzia manda una slide: tre barre verdi, una gialla, una nota che dice integrazioni all'80%. Un ambiente pubblicato non esiste. Non è mai esistito dal kickoff. Il progetto non sta ancora fallendo, ma lo farà.

La distanza fra quello che ti raccontano e quello che puoi aprire nel browser è il punto in cui i soldi di un progetto software spariscono. Uno studio di McKinsey e dell'Università di Oxford su oltre 5.400 progetti IT ha misurato che i progetti grandi sfondano il budget del 45%, i tempi del 7% e producono il 56% di valore in meno rispetto alle previsioni, con lo sforamento di costo che cresce di circa il 15% per ogni anno in più di durata (McKinsey, 2012). Quei numeri sono il punto d'arrivo. I segnali si vedono nel primo mese e per leggerli non serve saper programmare.

Eccone sette. Ognuno ha una spiegazione innocente e noiosa, quindi un segnale da solo è rumore. Tre insieme sono uno schema.

1. Chi ha fatto la trattativa non è chi sviluppa

Il senior che in call rispondeva a ogni domanda di architettura tace da tre settimane. Ai daily compaiono nomi nuovi. Chiedi perché una scelta è stata fatta in seconda settimana e in stanza non c'era nessuno.

È un problema strutturale, non una truffa: chi sa impostare un progetto è raro e viene ruotato sulle trattative. Il conto però lo paghi tu, in velocità che cala, domande che tornano e decisioni prese prima del passaggio di consegne che diventano leggenda orale.

Chiedi: i nomi di chi metterà mano al codice, il livello di seniority e il preavviso scritto prima di una sostituzione. Se non arriva una risposta in una email, quel team non è ancora stato messo insieme.

Spiegazione innocente: congedo parentale, malattia, un contratto finito. Allora chiedi il documento di handover. Se esiste, non è un segnale.

2. Arrivano stati di avanzamento, mai cose da aprire

Percentuali, semafori, un burndown. Nessuna URL, nessuno storico dei commit, nessuna lista dei difetti aperti. "Siamo all'80%" è un'affermazione, non una misura, e si può ripetere identica per quattro settimane.

Un team che alla fine della seconda settimana non ti mostra software che gira o non lo sta scrivendo o non vuole fartelo vedere. Il problema resta tuo in entrambi i casi.

Chiedi: un ambiente pubblicato ogni settimana, dalla seconda in poi, in qualunque stato si trovi. Brutto e incompleto va benissimo. Assente no. Insieme al log dei commit e al numero di bug aperti.

Spiegazione innocente: le prime due settimane erano davvero infrastruttura, login e pipeline. Allora alla terza arriva il link.

3. Il preventivo è arrivato prima delle domande

Prezzo pieno e tempi entro 48 ore da una sola call. Nessuno ha chiesto dei dati che hai già, degli obblighi di conformità, delle integrazioni, di chi approva un rilascio.

Il PMI attribuisce a una gestione dei requisiti approssimativa il 47% dei progetti che non raggiungono gli obiettivi (PMI, Pulse of the Profession). I requisiti non scompaiono perché nessuno li ha raccolti: riemergono dopo, come varianti da pagare, nel momento in cui hai meno potere contrattuale.

Chiedi: l'elenco scritto di cosa il preventivo esclude e su quali ipotesi si regge. Chi ha ragionato sul tuo progetto lo scrive in una pagina. Qui trovi cosa deve produrre davvero una fase di discovery.

Spiegazione innocente: il perimetro è piccolo e l'hanno già fatto undici volte. Allora la lista delle esclusioni sarà corta e precisa.

4. La velocità sale e la stabilità no

Le pull request si chiudono in fretta. La lista dei bug si allunga ogni venerdì. La stessa regressione è tornata due volte.

Il rapporto DORA 2025 sullo sviluppo assistito dall'AI, basato su quasi 5.000 risposte, ha rilevato che a un'adozione più alta di AI corrisponde maggiore instabilità nel rilascio, anche quando la produttività individuale cresce (DORA, 2025). Oggi il codice si genera più in fretta di quanto revisione e rilascio riescano ad assorbirlo. Nel 2026 un fornitore che rilascia troppo in fretta per restare corretto è un guasto più frequente di un fornitore lento.

Chiedi: tasso di fallimento dei rilasci e tempo di ripristino, non story point. Due numeri, ogni mese, in una email.

Spiegazione innocente: una settimana di migrazione pesante. Allora la curva dei difetti si appiattisce allo sprint dopo, e qualcuno te l'aveva anticipato.

5. Del perimetro te ne accorgi dalla fattura

Che il perimetro si muova è normale. I dati PMI stimano lo scope creep intorno al 41% dei progetti nell'arco di un anno (PMI). Il segnale non è il cambiamento: è dove lo scopri.

Se la prima volta che una modifica viene quotata è in fattura, un processo di gestione delle varianti non c'è, e l'incentivo gioca contro di te: ogni ambiguità del brief diventa ricavo.

Chiedi: un processo scritto per le varianti, concordato prima che serva, con tariffe e una soglia di approvazione sotto la quale le cose piccole si fanno e basta. Su dove va questa clausola abbiamo scritto la differenza fra SOW e MSA.

Spiegazione innocente: un'emergenza in produzione che non poteva aspettare una firma. Allora è successo una volta, e ti hanno chiamato.

6. Nessuno dice mai di no

Ogni richiesta riceve un sì. Nessuno nomina un compromesso, nessuno discute l'ordine delle cose, nessuno ti ha detto che una funzione costerà più di quanto renda.

Un fornitore senza opinioni o non sta pensando al tuo prodotto o conta di fatturarti le conseguenze del non averci pensato. La frase più utile che un'agenzia possa dirti è "questa cosa non la faremmo adesso, e ti spiego perché".

Mettili alla prova: chiedi qualcosa di costoso e un po' sciocco. Un'app mobile nativa al secondo mese. Una pipeline di analytics su misura prima di avere utenti. Guarda se qualcuno frena, e in quanto tempo.

Spiegazione innocente: le richieste che hai fatto finora erano sensate e ben ordinate. La prova si chiude in un giorno.

7. Il repository non lo puoi vedere

Il codice sta nella loro organizzazione. Gli accessi arrivano. Il contratto elenca i deliverable ma non dice di chi è il sorgente, e una clausola di deposito non c'è.

Questo segnale funziona diversamente dagli altri sei. Non predice la delusione: decide quanto ti costerà. Tutti gli altri problemi di questa lista si recuperano se hai in mano il codice e le credenziali di rilascio. Nessuno si recupera se non li hai.

Chiedi: il repository nella tua organizzazione dal primo commit, con l'agenzia invitata come collaboratrice, e gli account cloud intestati a te. Chi obietta deve saperti dire perché in una frase. Le formule contrattuali stanno in otto clausole da controllare.

Spiegazione innocente: un repo template condiviso nei primi giorni, migrato al kickoff. Chiedi la data.

Cosa fare quando ne hai contati tre

La mossa cara è il ricominciare in silenzio: sperare che lo sprint dopo aggiusti tutto mentre l'orologio gira. La durata è la variabile che moltiplica il costo, e ogni mese di attesa peggiora lo sforamento invece di ridurlo.

1. Scrivi cosa hai osservato, con le date e senza aggettivi. "Settimane 3, 5 e 7: chiesta una URL pubblicata, ricevuta una slide di stato." I fatti viaggiano, il fastidio no.
2. Manda il documento e chiedi una risposta scritta entro cinque giorni lavorativi. Il modo in cui rispondono è già il dato successivo.
3. Concorda due settimane di rientro con un solo risultato dimostrabile. Un ambiente che gira. Le persone concordate di nuovo in call. Un registro delle modifiche. Qualcosa che puoi aprire, non qualcosa che ti può essere raccontato.
4. Se la finestra si chiude vuota, usa la clausola di uscita. Prenditi repository, credenziali, documentazione e backlog. Poi fai una revisione del passaggio di consegne prima di scegliere chi subentra.

Come prevenirli tutti e sette prima di firmare

Quattro voci nei documenti tolgono di mezzo quasi tutto il rischio, e nessuna è una richiesta strana.

• Persone chiave indicate per nome nella SOW, con un preavviso scritto prima di sostituire qualcuno.
• Un ambiente pubblicato come milestone di pagamento entro le prime due settimane. Questa singola clausola elimina il segnale 2 e buona parte del 4.
• Repository e account cloud nella tua organizzazione dal primo commit.
• Un processo scritto per le varianti, con tariffe, concordato prima che esista la prima richiesta di modifica.

Se sei ancora alla fase di brief, quasi tutto costa meno risolverlo a monte: qui trovi come scrivere il brief per un'agenzia di sviluppo e gli errori più comuni dei founder che scelgono uno studio.

Noi stiamo dall'altra parte del tavolo, ed è esattamente il punto: sono le domande che ci aspettiamo da chi compra, e le stesse che faremmo noi se stessimo comprando. Nessuna richiede di saper leggere il codice. Richiedono che ogni affermazione sull'avanzamento arrivi attaccata a qualcosa che puoi aprire.