Errori da evitare quando si commissiona un software custom a un’agenzia

“Ma quanto ci vuole per farci una cosa semplice?”

Questa è la domanda più comune che arriva in fase di primo contatto. E la risposta onesta è: dipende da cosa intendi per “semplice”. Dietro quella parola si nasconde spesso il primo errore di un progetto software su misura.
Commissionare un software custom a un’agenzia tech non è complicato di per sé. Quello che manda i progetti fuori strada sono quasi sempre gli stessi errori, ripetuti da aziende diverse, in settori diversi. Questa lista li racconta uno per uno: come si manifestano, quanto pesano sul budget e sulla timeline, e cosa fare in modo diverso.

Dare per scontato che l’agenzia capisca il tuo business

L’errore più diffuso, e anche il più costoso.
Molte PMI arrivano al primo incontro con un’idea chiara in testa e la comunicano in modo implicito, dando per scontato che chi sviluppa software sappia già come funziona il loro settore. Un’agenzia tech conosce Laravel, Vue.js, le API, i database. Non conosce le tue eccezioni di magazzino, i tuoi accordi commerciali particolari, il modo in cui gestisci i resi.
Come si manifesta: il software viene consegnato, funziona tecnicamente, ma non copre i casi reali di utilizzo. Serve una seconda fase di sviluppo non preventivata.
Quanto costa: riscrivere una logica di business mal capita può valere dal 30 al 60% del costo iniziale del progetto, a seconda di quanto è centrale per il flusso principale.
Come si evita: prima di scrivere una riga di codice, l’agenzia dovrebbe condurre una fase di analisi dei requisiti con le persone che useranno il software ogni giorno, non solo con il responsabile IT o il CEO. Se l’agenzia salta questa fase o la riduce a una chiamata da 30 minuti, è un segnale da prendere sul serio.

Chiedere tutto subito, senza priorità

“Vorremmo anche la gestione delle notifiche, e poi un’area riservata per i clienti, e magari l’integrazione con il gestionale, e in futuro potremmo avere bisogno di…”
Ogni feature aggiunta in fase di brief allarga lo scope. Ogni allargamento di scope sposta la data di consegna e gonfia il preventivo. Questo lo sanno tutti, eppure succede sistematicamente.
Come si manifesta: il progetto parte con una lista di requisiti lunghissima. Dopo tre mesi di sviluppo, alcune funzionalità vengono ridimensionate perché il budget non regge, ma il tempo è già stato speso in architettura e pianificazione che teneva conto di tutto.
Quanto costa: uno scope mal definito è tra le cause principali di sforamento di budget nei progetti software su misura. Non è raro vedere progetti crescere del 40-80% rispetto alla stima iniziale per questa ragione.
Come si evita: costruire un MVP. Identificare le tre o quattro funzionalità senza cui il software non serve a niente, sviluppare quelle, usarle, poi decidere cosa aggiungere. Un articolo che abbiamo già pubblicato sui tempi reali di sviluppo software custom mostra come questa scelta impatti direttamente sulla timeline.

Scegliere l’agenzia sul prezzo più basso

Questa pratica è sbagliata quasi sempre, e lo diciamo senza giri di parole.
Un preventivo basso può significare tre cose: l’agenzia ha capito male i requisiti, userà sviluppatori junior senza supervisione, oppure taglierà sulla fase di testing e documentazione. In tutti e tre i casi, il risparmio iniziale si trasforma in costo di manutenzione o rifacimento entro dodici mesi.
Come si manifesta: il software viene consegnato nei tempi, ma con bug ricorrenti, senza documentazione tecnica, e con un codice che nessun altro sviluppatore riesce a leggere. Quando serve una modifica, l’unica opzione è tornare dalla stessa agenzia, che ora può chiedere quello che vuole.
Quanto costa: il vendor lock-in tecnico è difficile da quantificare, ma chi lo ha vissuto sa che può paralizzare lo sviluppo per mesi. Aggiungici il costo di un audit del codice e di una parziale riscrittura, e il risparmio iniziale svanisce.
Come si evita: valutare il preventivo insieme ad altri criteri. Chiedere referenze verificabili. Chiedere di vedere esempi di documentazione tecnica prodotta su altri progetti. Chiedere chi scriverà il codice e con quale processo di revisione. Per capire cosa preparare prima di chiedere un preventivo, questo articolo è un punto di partenza utile: cosa preparare prima di richiedere un preventivo software custom.

Non chiarire chi possiede il codice

Questo errore non rallenta il progetto. Lo mina alla base, e spesso ci si accorge del problema solo quando è troppo tardi.
Il codice sorgente di un software su commissione può appartenere al committente, all’agenzia, o essere in una zona grigia contrattuale. Se non è scritto nero su bianco nel contratto, valgono le interpretazioni, e le interpretazioni costano in sede legale.
Come si manifesta: l’azienda decide di cambiare agenzia o di internalizzare lo sviluppo. A quel punto scopre che il contratto firmato non trasferisce esplicitamente la proprietà intellettuale del codice, o che l’agenzia mantiene diritti sulle librerie custom sviluppate per il progetto.
Quanto costa: una causa civile per diritti software può durare anni. Anche solo la fase di consulenza legale e la rinegoziazione del contratto può valere diverse migliaia di euro, senza contare il blocco operativo nel mezzo.
Come si evita: prima di firmare qualsiasi contratto, verificare che contenga una clausola esplicita di cessione dei diritti patrimoniali sul codice sorgente al committente. Se l’agenzia usa librerie open source o componenti di terze parti, queste devono essere documentate con le rispettive licenze. Non è una formalità: è la base per poter evolvere il software liberamente in futuro.
Se stai valutando come scegliere un’agenzia di sviluppo software per la tua PMI, parla con noi del tuo progetto prima di firmare qualcosa.

Sparire durante lo sviluppo

Molti committenti pensano che il loro lavoro finisca quando il brief è consegnato. Poi ricompaiono alla demo finale e trovano qualcosa di diverso da quello che si aspettavano.
Lo sviluppo software non è una catena di montaggio dove si ordina un prodotto e si ritira finito. È un processo iterativo che richiede feedback continuo, soprattutto nelle prime settimane.
Come si manifesta: l’agenzia sviluppa seguendo la sua interpretazione dei requisiti. Il committente, non essendo coinvolto, non corregge la rotta. Alla consegna, le divergenze sono tante e profonde. Inizia una fase di revisioni non prevista che allunga i tempi di settimane o mesi.
Quanto costa: ogni settimana di revisione a progetto avanzato vale molto di più della stessa settimana spesa in analisi iniziale. Modificare un’architettura già costruita è sempre più oneroso che definirla bene prima.
Come si evita: concordare fin dall’inizio un ritmo di check-in regolari, almeno ogni due settimane. Nominare un referente interno che abbia autorità di prendere decisioni sui requisiti, senza dover coinvolgere ogni volta tre livelli di approvazione. Le demo intermedie servono proprio a questo: correggere prima che il costo della correzione diventi proibitivo.

Ignorare cosa succede dopo il go-live

Il software viene rilasciato. Tutti festeggiano. Poi, tre settimane dopo, arriva un aggiornamento del sistema operativo del server, o un’integrazione con un servizio esterno smette di funzionare, o gli utenti trovano un caso limite che nessuno aveva previsto.
Chi gestisce tutto questo?
Come si manifesta: il contratto non prevedeva una fase di manutenzione post-rilascio. L’agenzia considera il progetto chiuso. Il committente si trova a negoziare interventi urgenti senza un accordo quadro, spesso a tariffe orarie elevate e con tempi di risposta non garantiti.
Quanto costa: un’interruzione di servizio su un applicativo usato internamente ogni giorno può valere ore di lavoro perse per decine di persone. Su un software rivolto ai clienti, il danno reputazionale si aggiunge a quello operativo.
Come si evita: includere nel contratto iniziale un piano di manutenzione con SLA definiti: tempi di risposta per bug critici, aggiornamenti di sicurezza, modalità di gestione delle richieste di modifica. Abbiamo scritto in modo esteso su questo tema nell’articolo sulla manutenzione software custom per PMI.

Non documentare i requisiti per iscritto

L’ultimo errore della lista, non per importanza.
Le riunioni producono accordi verbali. Gli accordi verbali vengono ricordati in modo diverso da chi li ha presi. Questo vale per qualsiasi rapporto lavorativo, ma nel software ha conseguenze particolarmente concrete: una funzionalità “concordata a voce” che non compare nel documento di specifica non è una funzionalità prevista dal contratto.
Come si manifesta: a metà progetto emergono disaccordi su cosa era incluso e cosa no. L’agenzia dice che quella feature non era nel brief. Il committente è convinto che fosse stata discussa. Entrambi hanno ragione dal loro punto di vista.
Quanto costa: nel migliore dei casi, un ritardo e una rinegoziazione. Nel peggiore, una disputa che blocca la consegna.
Come si evita: ogni decisione presa in riunione deve essere messa per iscritto entro 24 ore, condivisa con entrambe le parti e approvata esplicitamente. Un documento di specifica funzionale non deve essere un romanzo: bastano poche pagine chiare, con casi d’uso descritti in linguaggio semplice. Se l’agenzia non produce questo documento, producilo tu.

Se stai per avviare un progetto software su misura e vuoi capire se i requisiti che hai in mente sono abbastanza solidi per un primo preventivo, raccontaci il tuo caso

Fa parte della guida Automazione processi PMI: quali flussi automatizzare prima con l’AI.