Quanto tempo ci vuole per sviluppare un software custom aziendale

Prima di chiedere “quanto tempo”: capisci cosa stai misurando

Un progetto software non ha una durata fissa. Ha una durata che dipende da cosa chiedi, da quanto sei pronto a rispondere durante il percorso, e da quante volte cambierai idea nel mezzo.
Detto questo, i range esistono e sono utili come punto di partenza. Un applicativo web con una manciata di funzionalità core, niente integrazioni esterne e un team dedicato: 2-4 mesi di sviluppo effettivo. Un gestionale aziendale con più moduli, connessioni a ERP o CRM esistenti, e flussi di approvazione complessi: 8-12 mesi, a volte di più.
Quello che di solito manca nelle stime che circolano online è la parte prima del codice: l’analisi. Senza contarla, qualsiasi timeline è falsa.

Passo 1 — Analisi dei requisiti: la fase che nessuno vuole pagare

Durata tipica: 2-6 settimane.
Cosa si fa: si mappa il processo che il software dovrà gestire, si identificano i casi d’uso, si definiscono le priorità tra funzionalità “must have” e “nice to have”, si verifica la fattibilità tecnica.
Cosa va storto di solito: il cliente arriva con un’idea in testa e vuole saltare direttamente allo sviluppo. L’analisi viene compressa in un paio di call, i requisiti restano vaghi, e il team inizia a costruire su fondamenta instabili. Il risultato? Richieste di modifica continue durante lo sviluppo, che allungano la timeline del 30-50% rispetto alla stima iniziale.
Un’analisi ben fatta produce un documento di specifiche funzionali che entrambe le parti firmano. Non è burocrazia: è l’unico modo per avere una stima dei tempi che regga.

Passo 2 — Progettazione tecnica e architettura

Durata tipica: 1-3 settimane, spesso sovrapposta alla fase di analisi.
Qui si decide lo stack tecnologico, si disegna l’architettura del database, si definisce come i moduli comunicheranno tra loro. Per applicazioni web custom, scelte come Laravel per il backend e Vue.js per il frontend hanno implicazioni precise su tempi e manutenibilità futura.
Cosa va storto: questa fase viene spesso saltata o ridotta a una conversazione informale. Il team inizia a scrivere codice senza avere chiaro il disegno complessivo. Funziona fino al terzo modulo, poi tutto diventa più lento perché ogni nuova feature richiede di toccare codice già scritto.
Un’architettura pensata male si paga per tutta la vita del progetto.

Passo 3 — Sviluppo iterativo: sprint, non cascata

Durata tipica: 60-70% del tempo totale del progetto.
Lo sviluppo su misura funziona meglio quando è organizzato in sprint di 1-2 settimane, con rilasci parziali e feedback frequenti. Ogni sprint produce qualcosa di funzionante e testabile, non solo codice in lavorazione.

Tipo di progetto	Durata sviluppo	Numero sprint indicativo
MVP / prototipo funzionale	6-12 settimane	3-6 sprint
Applicativo web con 3-5 moduli	3-6 mesi	6-12 sprint
Gestionale PMI completo	6-10 mesi	12-20 sprint
Piattaforma B2B con integrazioni	9-14 mesi	18-28 sprint

Questi numeri assumono un team che lavora a tempo pieno sul progetto. Con risorse condivise tra più clienti, moltiplica per 1.3-1.5.
Cosa va storto: il cliente non partecipa agli sprint review. Approva tutto in silenzio per tre mesi, poi alla demo finale dice che metà delle scelte non rispecchiano il suo processo reale. A quel punto si torna indietro, e il costo del ritardo ricade su entrambe le parti.

Passo 4 — Integrazioni esterne: il moltiplicatore di tempi

Ogni integrazione con un sistema esterno (ERP, CRM, piattaforme di pagamento, servizi di spedizione, API di terze parti) aggiunge tempo. Quanto? Dipende dalla qualità della documentazione dell’API esterna e da quanto il sistema di destinazione è standardizzato.
Un’integrazione con un’API ben documentata e stabile: qualche giorno. Un’integrazione con un gestionale legacy che espone i dati tramite file CSV o chiamate SOAP non documentate: settimane, a volte mesi.
Questa è la parte più sottovalutata nelle stime di progetto. Quando un cliente dice “ho già un ERP, basta collegarli”, il team tecnico sa che quella frase nasconde un’incognita enorme finché non si guarda dentro il sistema esistente.
Se il tuo progetto prevede integrazioni, chiediti subito: ho accesso alla documentazione tecnica del sistema da connettere? Ho un referente tecnico dall’altro lato? Se la risposta è no, aggiungi un buffer del 20-30% sulla timeline.

Passo 5 — Test e QA: non è l’ultima cosa da fare

Parla con noi del tuo progetto prima di ricevere il primo preventivo
Durata tipica: 15-20% del tempo totale di sviluppo.
Il testing non è una fase separata che arriva alla fine. O almeno, non dovrebbe esserlo. In un progetto ben organizzato, i test automatici vengono scritti durante lo sviluppo, e ogni sprint include una sessione di QA sul codice prodotto.
Cosa va storto: il testing viene compresso per rispettare una data di consegna. Si rilascia con bug noti, con la promessa di risolverli “nel prossimo aggiornamento”. Il cliente va in produzione, i bug diventano problemi operativi, la fiducia si rompe. Rimettere a posto un sistema già in produzione costa molto di più che testarlo prima.
Un’opinione netta: i progetti che saltano il testing sistematico non risparmiano tempo. Lo spostano in avanti, moltiplicato per tre.

Passo 6 — Rilascio, formazione e stabilizzazione

Durata tipica: 2-4 settimane dopo il go-live.
Il software è pronto. Non vuol dire che il progetto è finito. Il rilascio in produzione porta sempre sorprese: comportamenti imprevisti sotto carico reale, casi d’uso che non erano stati considerati in fase di analisi, utenti che usano il sistema in modi non previsti.
La formazione degli utenti finali è spesso sottovalutata. Un gestionale nuovo, anche se ben progettato, richiede un periodo di adattamento. Senza affiancamento iniziale, il tasso di adozione crolla e il cliente percepisce il software come “difficile da usare” anche quando non lo è.
Cosa va storto: il team di sviluppo chiude il progetto al rilascio e passa ad altro. Il cliente resta solo con domande operative. Questo è il momento in cui molti progetti custom vengono abbandonati o sostituiti, non per problemi tecnici, ma per mancanza di supporto nella transizione.

Cosa allunga davvero un progetto software

Tre fattori allungano i tempi più di qualsiasi complessità tecnica.
Il primo è il cambiamento dei requisiti a metà sviluppo. Non è un problema in assoluto (i requisiti evolvono, è normale), ma ogni cambio significativo ha un costo in tempo che va comunicato e accettato prima di procedere.
Il secondo è la latenza nelle decisioni. Se il cliente impiega una settimana a rispondere a una domanda tecnica, il team si blocca o va avanti con assunzioni che potrebbero essere sbagliate. Un referente interno dedicato, raggiungibile in 24 ore, vale settimane di timeline.
Il terzo è la qualità dei dati di partenza. Se il software deve importare dati da sistemi esistenti (anagrafiche clienti, catalogo prodotti, storico ordini), la pulizia e migrazione di quei dati è un lavoro a sé. Spesso scoperto solo a progetto avanzato.

FAQ

Q: Quanto tempo ci vuole per sviluppare un software custom aziendale?
A: Un MVP con funzionalità base richiede in genere 2-5 mesi. Un gestionale completo con integrazioni e moduli multipli può arrivare a 9-12 mesi. La fase di analisi iniziale, spesso sottovalutata, incide molto sulla durata totale: senza una buona analisi, qualsiasi stima è orientativa.
Q: Quali sono le fasi principali dello sviluppo di un software su misura?
A: Analisi dei requisiti, progettazione tecnica, sviluppo iterativo per sprint, test e QA, rilascio e formazione. L’analisi occupa in genere il 15-20% del tempo complessivo. Saltarla per risparmiare tempo produce l’effetto opposto.
Q: Quanto costa sviluppare un software custom per una PMI?
A: I costi variano in base a complessità, stack tecnologico e team. Qualsiasi cifra ricevuta senza un’analisi preliminare dei requisiti è da trattare come indicazione molto approssimativa. Prima si fa l’analisi, poi si costruisce una stima affidabile.
Q: Come si stima la durata di un progetto software aziendale?
A: Si scompone il progetto in moduli funzionali, si stima il tempo per ciascuno, si aggiunge un buffer per test e imprevisti. Con metodologie Agile le stime si aggiornano sprint per sprint, riducendo il rischio di scostamenti grandi a fine progetto. Una stima fatta a forfait prima dell’analisi serve solo a firmare un contratto, non a pianificare.

Se stai valutando un progetto software su misura e vuoi capire tempi e fattibilità prima di ricevere preventivi, in Press Start partiamo sempre da un’analisi tecnica dei requisiti. Raccontaci il tuo caso e ti diciamo cosa serve davvero per partire.