Quanto costa sviluppare un’app: perché i preventivi per la stessa applicazione sono così distanti e come confrontarli

Situazione tipo: un’azienda vuole un’applicazione su misura, invia le specifiche a tre fornitori e il più caro dei tre preventivi vale più volte il più economico. Il primo sospetto, di norma, è ovvio: qualcuno sta gonfiando il prezzo.

La differenza, però, può dipendere da che cosa il fornitore ha incluso nel preventivo, da che cosa ha omesso e da quale rischio ha lasciato a vostro carico.

Se un sistema su misura convenga lo analizziamo nell’articolo Un buon sistema interno può ripagarsi prima di una nuova assunzione. Qui partiamo dal passo successivo: i preventivi sono sul tavolo e la domanda è quanto costa sviluppare un’app, se ogni fornitore ne ha in mente una diversa.

Un preventivo che vale più volte un altro non è per forza gonfiato

In uno studio del 2009, Bente Anda, Dag Sjøberg e Audris Mockus hanno descritto la gara con cui il Simula Research Laboratory cercava un fornitore per un sistema web. Delle 81 aziende contattate in Norvegia, 35 hanno presentato un’offerta a prezzo fisso, tutte sulla stessa specifica di 11 pagine. Gli importi, IVA esclusa, andavano da 2.630 a 69.940 euro: il più alto era circa 26,6 volte il più basso. Istruttivo è il rapporto, non le cifre, ormai datate.

Le aziende, peraltro, ritenevano la specifica ben definita. Eppure le offerte differivano anche per la quantità di analisi e progettazione incluse, da nessuna fino a schermate, architettura e modelli dei dati. Gli autori non hanno trovato alcuna relazione tra il prezzo e il metodo di lavoro previsto e, secondo loro, dalle offerte si poteva capire solo in parte come lavorasse l’azienda e quale qualità intendesse garantire. La cifra, da sola, non dice quindi che cosa otterrete in cambio.

Nella fase preliminare della stessa gara, 17 di queste aziende avevano fornito una stima non vincolante basata soltanto su una descrizione delle esigenze lunga una pagina. Secondo Magne Jørgensen e Gunnar J. Carelius, la stima più alta era circa dieci volte la più bassa, tra l’altro per differenze nelle soluzioni proposte e nella produttività. Gli autori avvertono che, con una specifica vaga, il prezzo dell’offerta non solo riflette il progetto, ma lo definisce.

Costo sviluppo app: le voci che lo compongono

Se le specifiche tacciono, queste decisioni le prende il fornitore al posto vostro:

• Perimetro funzionale. Che cosa l’app farà e che cosa non farà. La frase «l’utente genera un report» può indicare tanto un’esportazione in un foglio di calcolo quanto un modulo di analisi.
• Integrazioni. I collegamenti, per esempio, con il software di contabilità. La loro complessità dipende da interfacce che il fornitore potrebbe non conoscere.
• Design e UX. La UX, cioè l’esperienza utente, incide sul fatto che le persone adottino o meno l’app, come spieghiamo nell’articolo Il sistema più caro è quello che le vostre persone non usano. Un template già pronto costa meno di una progettazione verificata con gli utenti.
• Modello dei dati. La struttura dei dati e delle loro relazioni. Tutto il resto poggia su di esso, per questo i suoi errori si correggono a fatica.
• Sicurezza e permessi. Un unico ruolo per tutti costa poco, mentre gli accessi differenziati per mansione vanno progettati e anche testati.
• Test. I test automatici verificano, dopo ogni modifica, che ciò che funzionava continui a funzionare. Senza di essi, a testare sono i vostri collaboratori.
• Project management. Coordinamento e gestione delle modifiche. Verificate se è compreso nel prezzo o se dovrà occuparsene qualcuno dei vostri.

Le differenze si nascondono anche nei requisiti non funzionali, che non descrivono che cosa fa il sistema, ma quanto bene lo fa: velocità, affidabilità o manutenibilità, cioè quanto è facile modificarlo. Nello studio norvegese erano descritti in modo meno dettagliato di quelli funzionali e gli autori raccomandano di specificarli, in particolare la manutenibilità, già nella richiesta d’offerta. Può essere utile il modello di qualità della norma ISO/IEC 25010:2023, che anche i committenti possono usare per definire le specifiche.

Che cosa può mancare nel preventivo

Verificate queste voci con ciascun fornitore. Se le specifiche non le menzionavano, uno può averle incluse e un altro no.

• Pannello di amministrazione. Gestione di utenti, tabelle di riferimento e contenuti. Senza, ogni piccola modifica passa da uno sviluppatore e finisce in fattura.
• Migrazione dei dati. Trasferimento e pulizia dei dati dal vecchio sistema o dai fogli di calcolo.
• Supporto multilingua. Se il codice non lo prevede fin dall’inizio, aggiungerlo può toccare gran parte dell’applicazione.
• Accessibilità. L’usabilità anche per le persone con disabilità. Affrontarla a posteriori significa rifare schermate già pronte.
• Supporto dopo l’avvio. Correzioni, aggiornamenti di sicurezza e assistenza agli utenti. Se manca, il primo problema in produzione diventa un nuovo ordine.

I costi nell’arco degli anni di utilizzo li analizziamo nell’articolo Sette SaaS o un solo sistema? Per leggere un preventivo basta tenerne a mente una cosa: il codice senza test e documentazione costa meno da consegnare, ma di più da modificare, perché a ogni intervento lo sviluppatore deve prima capire che cosa la modifica rischia di rompere.

Chi si assume il rischio: prezzo fisso, time and material, modello ibrido

Con il prezzo fisso il rischio di sforare i costi è a carico del fornitore, che per questo lo incorpora nel prezzo: più le specifiche sono vaghe, più ampia è la riserva o più restrittiva l’interpretazione del perimetro. Il Federal Acquisition Regulation, il regolamento statunitense sugli appalti federali, afferma che il contratto a prezzo fisso pone sul fornitore il rischio massimo e che il tipo di contratto va negoziato insieme al prezzo. Non fa parte del nostro ordinamento, ma a nostro avviso la sua logica è trasferibile.

Con il time and material pagate le ore lavorate secondo tariffe concordate e il rischio dell’incertezza resta a vostro carico. Lo stesso regolamento lo ammette solo quando non è possibile stimare con precisione in anticipo l’entità o la durata del lavoro. Poiché questo modello non incentiva il fornitore a contenere i costi, il regolamento prescrive la sorveglianza da parte del committente. Prescrive inoltre un tetto di prezzo, che il fornitore supera a proprio rischio.

Il modello ibrido con una prima milestone a prezzo fisso blocca il costo della prima fase, che ha un risultato chiaro, per esempio un’analisi o un prototipo, mentre sul resto si decide solo quando il perimetro è stato descritto. Il fornitore si fa carico del rischio di una fase piccola e voi decidete sulla maggior parte del budget con informazioni migliori. La prima fase, però, costa denaro e tempo, e il suo risultato deve poter essere usato anche da un altro fornitore, altrimenti comprate la dipendenza con una fase d’anticipo.

Le specifiche imprecise si pagano durante lo sviluppo

La change request è una richiesta formale di modifica del perimetro concordato, con un prezzo proprio e un impatto sui tempi di consegna. Con specifiche imprecise l’eccezione diventa la regola, perché le parti mancanti emergono solo durante lo sviluppo.

Jørgensen e Carelius riportano che una causa frequente degli sforamenti di costo del fornitore sono le modifiche ai requisiti che non si possono fatturare al cliente. Chi si è aggiudicato il lavoro con un prezzo basso ha quindi, a nostro avviso, un forte incentivo a fatturare come modifica ogni scostamento. Se il contratto non stabilisce in anticipo la tariffa, il metodo di stima e l’approvazione delle modifiche, ne negozierete il prezzo quando sostituire il fornitore non sarà più semplice.

Le specifiche imprecise, però, non si pagano solo in fattura. Il framework Cost of Friction, che usiamo sul blog, calcola il costo dell’attrito come tempo × frequenza × numero di persone × costo. Calcolo esemplificativo con dati ipotetici: 30 punti poco chiari nelle specifiche, ciascuno dei quali richiede due ore di riunione con tre vostri collaboratori, significano 2 × 30 × 3 = 180 ore di lavoro interno. Nessuno ve le fatturerà, eppure le pagherete. Inserite i vostri numeri e il vostro costo orario.

Diritti sul codice e possibilità di cambiare fornitore

Il vendor lock-in è la situazione in cui non potete sostituire facilmente il fornitore, perché il sistema lo capisce solo lui. Nel 2016 la Commissione europea ha riferito che il 42% delle organizzazioni esaminate ha dichiarato di aver subito un lock-in in ambito ICT.

Secondo il § 91, comma 4, della legge slovacca sul diritto d’autore n. 185/2015 Z. z., nel testo in vigore dal 1° settembre 2026, a un programma per elaboratore creato in tutto o in parte su commissione si applicano le disposizioni sull’opera creata dal dipendente e il committente è considerato datore di lavoro. Salvo diverso accordo, il committente esercita quindi i diritti patrimoniali, in particolare il diritto di utilizzare l’opera, può cederne l’esercizio a terzi e si considera che l’autore abbia acconsentito anche alla modifica dell’opera (§ 90, commi da 4 a 6). Questo è il diritto slovacco; altri Paesi possono disciplinare la materia in modo diverso. In qualunque Paese, quindi, il contratto dovrebbe indicare in modo esplicito a chi appartiene il codice.

Per opera su commissione la legge intende un’opera creata sulla base di un contratto d’opera, e conta anche ciò che le parti hanno concordato. La legge, inoltre, disciplina i diritti, non la consegna: senza il codice sorgente nel vostro repository, gli accessi e la documentazione, il diritto di modificare l’opera vi servirà a poco.

Il contratto dovrebbe disciplinare anche le parti già pronte che il fornitore porta con sé, per esempio la sua piattaforma o componenti a pagamento, perché queste non sono nate su vostra commissione. Non si tratta di consulenza legale: fate esaminare il contratto da un avvocato.

Come confrontare i preventivi

Inviate a tutti i fornitori le stesse domande e riportate le risposte una accanto all’altra:

1. Che cosa rientra nel perimetro e che cosa ne escludete esplicitamente?
2. Quali ipotesi avete fatto su integrazioni, dati e ruoli?
3. Come gestite prestazioni, sicurezza e manutenibilità, e che cosa testate?
4. Come quotate e come approvate le modifiche al perimetro?
5. Che cosa comprende il supporto dopo l’avvio e quanto costa il primo anno di esercizio?
6. Quali diritti sul codice otterremo, dove sarà conservato e come avverrà il passaggio a un altro fornitore?

Gli autori dello studio norvegese raccomandano che le offerte dichiarino esplicitamente i metodi di lavoro e le ambizioni di qualità, e non solo in modo implicito nel prezzo fisso. Come segnali d’allarme consideriamo:

• Prezzo fisso senza domande. Specifiche vaghe quotate con una cifra fissa senza domande di chiarimento possono poggiare su un’interpretazione restrittiva del perimetro o su una riserva di cui non sapete nulla.
• Test assenti. Gli errori, allora, li scopriranno solo i vostri utenti.
• Diritti e accessi poco chiari. Non è chiaro dove sarà conservato il codice, oppure gli accessi sono legati alla durata della collaborazione.

Quando il preventivo più economico è la scelta giusta

Alla fine quattro aziende dello studio norvegese hanno sviluppato il sistema, ciascuna in modo indipendente. La più economica, con un prezzo di 8.750 euro, ha accumulato un ritardo del 93% rispetto ai tempi concordati, con affidabilità e manutenibilità scarse. La più cara, con un prezzo di 56.000 euro, ha registrato un ritardo del 5%, con buona usabilità e buona manutenibilità. In base al prezzo era 6,4 volte più cara, ma includendo il lavoro del committente soltanto 3,4 volte. I risultati non hanno rispecchiato l’ordine dei prezzi e, secondo gli autori, il sistema più economico poteva essere la scelta migliore per un committente che tollera i ritardi, dispone di competenze sufficienti e ha esigenze meno elevate su alcuni aspetti della qualità.

Può trattarsi, per esempio, di uno strumento interno destinato a durare poco o della verifica di un’idea.

Nei dati di Magne Jørgensen su 785.325 incarichi, per lo più molto piccoli, affidati su un marketplace globale di outsourcing, il fattore che riduceva di più il rischio di fallimento era una precedente collaborazione tra cliente e fornitore, che lo portava al 17% del livello dei progetti che ne erano privi. I clienti che avevano scelto un’offerta con un prezzo almeno pari alla media avevano, a parità di altre condizioni, un rischio pari all’85% di quello dei clienti che davano più peso al prezzo basso. Secondo l’autore, questi risultati si possono generalizzare ai progetti più grandi solo con cautela. A suo giudizio, il modo migliore per valutare un fornitore è una prova realistica, per esempio un progetto vero, e questa prova può essere una piccola prima fase a pagamento.

La fase iniziale trasforma la stima in un piano

Steve McConnell descrive il cono dell’incertezza, un modello che mostra come migliora la precisione delle stime nel corso del progetto. Nella fase di concept iniziale anche gli stimatori esperti possono sbagliare di un fattore quattro, per eccesso o per difetto, cioè con una forbice complessiva di 16 volte, e secondo lui più precisi di così non si può essere. Il cono non si restringe con un’altra settimana dedicata alla stima, ma soltanto con le decisioni su che cosa il prodotto farà e non farà, sui requisiti e sull’interfaccia utente.

Queste decisioni arrivano con un’analisi o un prototipo. A quel punto i fornitori quotano almeno lo stesso perimetro, anche se questo non garantisce prezzi simili, come ha mostrato lo studio norvegese.

Le aziende che nella gara citata avevano prima fornito una stima sulla base della descrizione di una pagina hanno poi offerto, sulla specifica dettagliata, prezzi mediamente più alti delle altre. Per questo Jørgensen e Carelius raccomandano di non chiedere prezzi indicativi sulla base di informazioni incomplete, se le offerte finali possono basarsi su informazioni più complete.

Un’analisi a pagamento, del resto, non è obbligatoria. Per un’app piccola e ben delimitata può bastare precisare le specifiche con le risorse interne. L’analisi può anche mostrare che lo sviluppo non vi serve, perché il problema si risolve semplificando il processo o con uno strumento già pronto. Per questo alla domanda su quale sia il costo di sviluppo di un’app non esiste una risposta onesta finché non è chiaro quale problema l’app debba risolvere.

Cosa portarsi a casa

• Se un preventivo vale più volte un altro, non è detto che sia gonfiato. Può riflettere un perimetro diverso, un’altra soluzione o una riserva per il rischio.
• Inviate a tutti i fornitori le stesse domande e confrontate perimetro, esclusioni e ipotesi, non soltanto le cifre finali.
• Se le specifiche si possono precisare, non chiedete prezzi indicativi su una descrizione vaga. Con un perimetro poco chiaro, partite da una fase iniziale a prezzo fisso, il cui risultato possa essere usato anche da un altro fornitore.
• Prima della firma, disciplinate nel contratto diritti sul codice, accessi, documentazione e componenti già pronti, e fatelo esaminare da un avvocato.
• Il preventivo più economico può essere la scelta giusta se potete tollerare i ritardi, avete esigenze di qualità meno elevate e disponete delle competenze per controllare la fornitura.