Quanto dura uno sviluppo software custom? Tempi reali per PMI

Hai ricevuto una proposta di sviluppo software e ti hanno detto “ci vogliono tre mesi”. Tre mesi dopo il progetto è ancora in corso, con metà delle funzionalità mancanti e una lista di “piccole modifiche” che continua ad allungarsi. Questa storia la conosce quasi chiunque abbia commissionato software su misura almeno una volta.
I tempi di sviluppo software custom sono tra i dati più difficili da stimare e, spesso, i più sottovalutati. In questo articolo vediamo come funziona davvero una timeline, quali variabili la determinano e come leggere una proposta di progetto senza farti sorprendere.

Perché le stime saltano quasi sempre

Partiamo da un dato scomodo: la maggior parte delle stime sui tempi di sviluppo software sono ottimistiche per definizione. Chi le produce vuole vincere il progetto. Chi le riceve vuole sentire tempi brevi. Il risultato è che entrambe le parti firmano un contratto su numeri che nessuno crede davvero.
Il problema non è la malafede. È che stimare software è difficile quanto stimare quanto tempo ci vorrà per scrivere un libro: dipende da cosa devi scrivere, da quante volte cambierai idea, da quanti revisori hai e da quanto sono veloci a rispondere.
Le variabili che pesano di più sulla durata reale di un progetto software su misura sono quattro:

1. Chiarezza dei requisiti all’avvio — un documento di analisi dettagliato vale settimane di lavoro risparmiate
2. Numero e complessità delle integrazioni — ogni API esterna o sistema legacy da collegare porta con sé incognite
3. Velocità di feedback del cliente — i cicli di revisione allungano la timeline quanto lo sviluppo stesso
4. Stabilità dello scope — ogni funzionalità aggiunta in corso d’opera ha un costo moltiplicato rispetto a quanto sarebbe costata in fase di analisi

Nessuna di queste variabili è tecnica. Sono tutte organizzative e comunicative. Questo è il motivo per cui due agenzie con lo stesso stack tecnologico possono avere performance di consegna molto diverse.

Le fasi di un progetto software su misura

Un progetto di sviluppo software custom segue sempre le stesse fasi di base, anche se cambiano i nomi e le metodologie. Capire cosa succede in ciascuna ti permette di valutare meglio le proposte che ricevi.

Analisi e definizione dei requisiti

Questa è la fase più sottovalutata, spesso trattata come una formalità da sbrigare in fretta. È un errore.
Un’analisi seria richiede tra una e tre settimane, a seconda della complessità. Produce un documento funzionale che descrive cosa il software deve fare, come si comporta in ogni scenario e quali sistemi deve integrare. Senza questo documento, qualsiasi stima successiva è priva di fondamento.
Se un fornitore ti propone di saltare questa fase “per risparmiare tempo”, considera che stai firmando per un progetto senza mappa.

Progettazione dell’architettura

Dopo l’analisi, prima di scrivere una riga di codice, si definisce come il sistema è costruito. Scelte come il framework backend (Laravel, Django, Node.js), la struttura del database, la gestione dell’autenticazione e le API interne si prendono qui. Cambiarle a metà sviluppo è costoso.
Questa fase dura in genere da una a due settimane per progetti di media complessità.

Sviluppo iterativo per sprint

È la fase più lunga. Il lavoro viene organizzato in sprint di una o due settimane, ciascuno con un set di funzionalità da completare e consegnare. Alla fine di ogni sprint il cliente vede qualcosa di funzionante, non solo un report.
La durata totale dipende dal numero di sprint necessari, che a sua volta dipende dalla quantità di funzionalità da sviluppare. Qui entra in gioco lo scope creep: ogni funzionalità aggiunta in corso richiede un nuovo sprint o allunga quelli esistenti.

Test e quality assurance

I test non sono un’aggiunta opzionale. Un’applicazione che va in produzione senza test strutturati è un’applicazione che romperà qualcosa di importante nel momento peggiore possibile.
Questa fase occupa in genere il 15-20% del tempo totale di sviluppo. Su un progetto da 12 settimane di sviluppo, sono due settimane di test. Chi ti dice che i test si fanno “in parallelo senza impatto sui tempi” probabilmente li sta saltando.

Rilascio, go-live e supporto iniziale

Il go-live non è la fine del progetto. C’è una fase di stabilizzazione post-lancio, in cui emergono comportamenti inattesi in produzione che non erano visibili in ambiente di test. Pianifica almeno due o tre settimane di supporto attivo dopo il rilascio.

Quanto dura davvero: riferimenti per tipo di progetto

Dare numeri precisi senza conoscere i requisiti è impossibile. Però è possibile ragionare per categorie di progetto.

Tipo di progetto	Complessità indicativa	Range temporale orientativo
MVP con funzionalità core (3-5 feature principali)	Bassa-media	8-16 settimane
Applicazione gestionale con pannello admin e ruoli utente	Media	4-7 mesi
Piattaforma con più moduli, integrazioni esterne e workflow complessi	Alta	6-12 mesi
Riscrittura di un sistema legacy con migrazione dati	Alta-molto alta	8-18 mesi

Questi range assumono un team dedicato, requisiti stabili e un cliente che risponde ai feedback entro 48 ore. Se una di queste condizioni manca, i tempi si allungano.

Il vero problema con i preventivi a forfait

C’è una pratica diffusa nel settore che, secondo noi, fa più danni di quanto sembri: il preventivo a forfait con tempi fissi firmato prima dell’analisi.
Funziona così: il cliente descrive a grandi linee cosa vuole, il fornitore produce un preventivo con tempi e costi in 48 ore, si firma e si inizia. Sembra efficiente. In realtà è una scommessa che perde sempre qualcuno: o il fornitore che ha sottostimato il lavoro, o il cliente che si trova con funzionalità tagliate per rispettare il budget.
La pianificazione progetto software custom seria inizia con un’analisi pagata separatamente, che produce un documento di requisiti, e solo dopo produce una stima credibile. Questa sequenza richiede più tempo all’avvio, però elimina la maggior parte delle sorprese in corso.
Se stai valutando fornitori, chiedi come gestiscono le variazioni di scope durante il progetto. La risposta ti dice molto su quanto la stima iniziale sia affidabile.

Se stai pianificando un progetto software e vuoi capire quanto tempo realistico aspettarti per il tuo caso specifico, in Press Start facciamo analisi tecniche preliminari prima di qualsiasi stima. Raccontaci il tuo progetto e vediamo insieme cosa serve davvero.

Come leggere una timeline proposta da un fornitore

Quando ricevi una proposta con una timeline, verifica questi punti prima di firmare.
Le fasi di analisi e test devono essere presenti come voci separate, con ore o settimane stimate. Se non compaiono, o sono incluse “nel totale” senza dettaglio, è probabile che siano sottostimate o assenti.
Chiedi cosa succede se i requisiti cambiano. Un fornitore serio ha una procedura di change request documentata: ogni modifica viene valutata, stimata e approvata prima di essere sviluppata. Se la risposta è “ci adattiamo”, preparati a discussioni sui costi a progetto avanzato.
Chiedi anche con quale cadenza vedrai qualcosa di funzionante. Sprint di due settimane con demo al cliente sono uno standard ragionevole. Se il fornitore prevede di mostrarti il prodotto finito solo a fine progetto, stai lavorando senza rete di sicurezza.

Pianificazione sprint: come funziona in pratica

Nelle fasi di sviluppo software per PMI, la metodologia a sprint è diventata lo standard per buone ragioni. Ogni sprint ha un backlog definito all’inizio, un obiettivo misurabile e una demo al termine. Il cliente può vedere i progressi, dare feedback in tempo reale e, se necessario, riorientare le priorità prima che il costo di un cambio di direzione diventi proibitivo.
Uno sprint tipico dura una o due settimane. In uno sprint di due settimane un team di due sviluppatori riesce a completare tra tre e sei funzionalità di media complessità, a seconda della loro natura. Le integrazioni con sistemi esterni tendono a richiedere più tempo del previsto, perché la documentazione delle API terze è spesso incompleta o non aggiornata.
La timeline sviluppo applicazione custom più affidabile è quella costruita sprint per sprint, con una stima aggiornata a ogni ciclo. Non è meno precisa di una stima fissa: è più onesta.

Quando accelerare non conviene

C’è una pressione costante a comprimere i tempi. “Possiamo farcela in meno?” è una domanda legittima. La risposta onesta è: dipende da cosa sei disposto a sacrificare.
Si può accelerare riducendo lo scope (meno funzionalità nella prima versione), aumentando il team (con un costo crescente e un rischio di coordinamento), o tagliando i test (sconsigliato sempre, senza eccezioni).
Quello che non si può fare è mantenere lo stesso scope, lo stesso budget e dimezzare i tempi. Chi ti promette questa combinazione sta comprando il contratto, non pianificando il progetto.
Un MVP ben fatto in 12 settimane vale più di un prodotto completo “quasi pronto” dopo 8 mesi di slittamenti. Questa è la logica che guida la pianificazione progetto software custom fatta bene.

FAQ

Q: Quanto dura in media un progetto di sviluppo software custom per una PMI?
A: Dipende dalla complessità. Un MVP con funzionalità core richiede in genere tra 8 e 16 settimane. Un’applicazione completa con integrazioni e pannelli di amministrazione può arrivare a 6-12 mesi. La variabile più impattante è la chiarezza dei requisiti all’avvio.
Q: Quali sono le fasi principali di un progetto software su misura?
A: Le fasi standard sono: analisi e definizione dei requisiti, progettazione dell’architettura, sviluppo iterativo per sprint, test e quality assurance, rilascio e go-live, supporto post-lancio. Ogni fase ha una durata variabile in base alla complessità del progetto.
Q: Cosa rallenta di più la timeline di sviluppo di un’applicazione custom?
A: I ritardi più comuni arrivano da requisiti cambiati in corsa, feedback del cliente lenti sulle revisioni, integrazioni con sistemi legacy non documentati e scope creep non gestito. Una buona analisi iniziale riduce questi rischi in modo significativo.
Q: È possibile avere una stima dei tempi prima di iniziare il progetto?
A: Sì, ma solo dopo un’analisi tecnica dei requisiti. Stime date senza analisi sono numeri casuali. Un’analisi seria richiede 1-2 settimane e produce una timeline con margini realistici, non promesse.
Q: Cosa si intende per MVP nello sviluppo software custom?
A: MVP sta per Minimum Viable Product: la versione del software con le sole funzionalità necessarie a validare il prodotto o risolvere il problema principale. Costruire un MVP prima della versione completa riduce i rischi e accorcia i tempi di rilascio iniziale.

Se stai valutando un progetto software su misura e vuoi una stima costruita su requisiti reali, non su ipotesi, in Press Start partiamo sempre dall’analisi tecnica. Raccontaci il tuo caso e capiamo insieme cosa ha senso fare e in quanto tempo.

Fa parte della guida Preventivo sviluppo software custom: cosa chiedere (e cosa aspettarsi).