Quanto costa la discovery nel 2026: cosa pagare e cosa no

La discovery è un lavoro a pagamento, con perimetro chiuso, che trasforma un progetto software indefinito in un progetto con un prezzo. Compri tre-sei settimane di attenzione di un team. Ti tornano indietro un perimetro, un piano tecnico, un prototipo e un numero abbastanza solido da metterlo a budget. Nel 2026 la tariffa di mercato sta tra i 5.000 e i 30.000 dollari per la maggior parte dei prodotti piccoli e medi: più o meno il 5-10% del costo della build che stai per commissionare.

Il problema di chi compra è questo. Una discovery vera e una telefonata di vendita travestita producono gli stessi artefatti: una cifra fissa, qualche settimana, un documento alla fine. La differenza si vede quattro mesi dopo, quando la stima regge oppure raddoppia. Quindi la domanda utile prima di firmare va oltre il prezzo medio. Riguarda cosa devono comprare quei soldi perché la cifra sia difendibile.

Quanto costa una discovery nel 2026?

I listini pubblicati dagli studi di sviluppo nel 2026 si concentrano in una fascia stretta, e la fascia segue la dimensione del progetto più del prestigio dello studio. Vanno letti come prezzi di mercato, non come uno standard: nessun ente indipendente li certifica.

• 5.000-12.000 dollari. Prodotto piccolo, concept chiaro, poche integrazioni, un solo tipo di utente. Due-tre settimane.
• 12.000-30.000 dollari. Progetto mid-market con diverse integrazioni, più ruoli e permessi, migrazioni di dati da capire. Tre-sei settimane.
• Oltre 40.000 dollari. Lavoro enterprise o regolamentato, dove la mappatura della compliance e l'integrazione con il legacy si mangiano quasi tutto il calendario.

La regola percentuale è il controllo più affilato: di solito la discovery vale il 5-10% della build che sta preventivando. Su una build da 180.000 dollari, una discovery da 12.000 è normale. Una da 2.000 è una telefonata di vendita con una fattura attaccata. Una da 60.000 vuol dire che stai pagando tariffe di sviluppo per pianificare, e che qualcuno ha già cominciato a costruire.

Perché l'argomento "1 dollaro adesso, 100 dopo" non regge

Quasi tutti gli studi che vendono discovery tirano fuori la stessa giustificazione: un difetto individuato in fase di requisiti costa 1 dollaro, lo stesso difetto dopo il rilascio ne costa 100. La curva viene attribuita a Barry Boehm e la si cita da quarant'anni.

Sotto, le prove sono poche. I numeri originali risalgono a materiale di formazione interno IBM, non a uno studio con revisione dei pari, e nel 2001 lo stesso Boehm ha portato il rapporto vicino a 5:1 per i sistemi piccoli e non critici. Nel 2017 Menzies e colleghi hanno messo alla prova la tesi su 171 progetti software realizzati fra il 2006 e il 2014, lo studio più ampio mai pubblicato sul fenomeno, e non ne hanno trovato traccia. Risolvere un problema tardi non è risultato né sistematicamente né sensibilmente più oneroso che risolverlo appena comparso. La loro lettura: l'effetto compare a intermittenza in certi tipi di progetto, e non va preso per una legge del software.

Quando uno studio ti vende la discovery appoggiandosi a quella curva, sta usando folklore. Il lavoro può valere lo stesso i soldi che chiede. L'argomento però deve reggersi su qualcosa di meglio di un numero uscito da un corso aziendale del 1981.

Il motivo vero per cui la discovery vale il suo prezzo

I requisiti stanno al centro dei progetti falliti, e lì i dati sono più solidi della curva dei costi. Il report Pulse of the Profession del PMI sulla gestione dei requisiti ha rilevato che il 47% dei progetti non riusciti manca gli obiettivi per una gestione imprecisa dei requisiti. La ricerca CHAOS dello Standish Group mette requisiti e specifiche incompleti in cima ai fattori dietro i progetti in difficoltà, al 12,3%, e una definizione chiara dei requisiti al terzo posto fra i fattori dietro quelli riusciti, al 13,0%.

Guarda bene cosa descrivono quei numeri. Il modo tipico di fallire è costruire la cosa sbagliata con competenza, nei tempi, a specifica. La discovery aggredisce proprio quello. Costringe a prendere le decisioni che su carta costano un pomeriggio e dentro una codebase costano un trimestre: per chi è questo prodotto, cosa esce per primo, che forma ha il modello dati, cosa resta fuori dal perimetro.

Il secondo motivo è commerciale. Un progetto indefinito non si può preventivare onestamente. Uno studio che spara un prezzo fisso su un brief di due pagine o gonfia la cifra per coprirsi il rischio, o conta di recuperare dopo con le richieste di modifica. La discovery trasforma le supposizioni in un perimetro su cui entrambe le parti si possono tenere. Compri una stima di cui ti fidi, e la libertà di andartene tenendotela.

Cosa deve produrre una discovery

Il prezzo si giudica sui deliverable, mai sul calendario. Una discovery difendibile consegna tutto questo:

• Un perimetro con le priorità. Ogni funzione ordinata, con la linea dell'MVP tracciata. Scritto, non discusso a voce.
• Flussi utente e wireframe. Schermata per schermata, come si arriva in fondo al compito principale. Nel 2026 lo standard è un prototipo cliccabile in Figma.
• Un brief tecnico. Stack, modello dati, piano delle integrazioni, autenticazione, hosting. Dettagliato al punto che un altro team lo legge e parte.
• Una stima con intervalli. Costi e tempi per milestone, con l'incertezza dichiarata voce per voce invece che sepolta in un'unica percentuale di contingenza.
• Ipotesi ed esclusioni. L'elenco che nessuno scrive volentieri. È quello che evita la lite al quarto mese.
• I rischi, con un nome. Le tre cose che più probabilmente fanno saltare la stima, ognuna con il suo impatto economico.

Se quello che ti consegnano è una presentazione di findings con un numero sull'ultima slide, hai pagato una proposta. Le proposte sono gratis.

Quando il prezzo è sbagliato

Due direzioni, due problemi diversi.

Troppo poco. Sotto il 3% circa della build, la cifra non copre le ore che il lavoro richiede. Qualcuno sta assorbendo la differenza come costo commerciale, e quindi il risultato serve la vendita. Una discovery gratis o quasi è un'offerta, e le offerte si scrivono per vincere, non per essere accurate.

Troppo. Sopra il 15% circa, guarda bene i deliverable. Design ad alta fedeltà di ogni schermata, un backend funzionante, ottanta pagine di documento dei requisiti: sono attività di sviluppo con l'etichetta discovery. Comprarle va benissimo. Va bene meno pagarle come discovery quando sono build, e impegnarsi prima ancora che la stima esista.

Sulla durata il controllo è più semplice. Quasi tutte le discovery stanno fra tre e sei settimane, con quattro come misura più frequente. Oltre, o il progetto è davvero complesso (regolamentato, legacy da integrare, tanti interlocutori), oppure la discovery è diventata un progetto per conto suo.

Cosa non devi pagare

Dentro una discovery a pagamento finisce spesso lavoro commerciale che gli studi hanno sempre fatto gratis:

• Le prime una o due call, forbice di budget di massima compresa.
• La presentazione delle competenze o la rassegna dei casi studio.
• La proposta scritta per la discovery stessa.
• Una valutazione a grandi linee su quanto il tuo progetto sia adatto.

La linea è facile da tracciare. Se l'artefatto ha valore per te solo dal momento in cui assumi quello studio, è vendita. Se conserva il suo valore quando lo porti a un altro team, è lavoro, e il lavoro si paga.

Un esempio concreto: 12.000 dollari di discovery su una build da 180.000

Prendiamo un SaaS B2B: multi-tenant, fatturazione con Stripe, un back office di amministrazione, un'integrazione con terze parti. Build attesa sui 180.000 dollari, in linea con le cifre che vediamo per quel perimetro.

Una discovery da 12.000 dollari su quattro settimane è proporzionata: il 6,7%. Per quella cifra: workshop con le persone che il dominio lo conoscono davvero, un backlog con le priorità e la linea dell'MVP tracciata sopra, un prototipo cliccabile dei quattro flussi principali, un brief tecnico su modello di tenancy e architettura di fatturazione, stime per milestone con intervalli, e una lista di rischi in cui l'integrazione con Stripe e la scelta sulla tenancy hanno nome e impatto economico.

E adesso la prova che conta. Passa quel pacchetto a un secondo studio e chiedigli di preventivare da lì. Se torna con un numero vicino al primo, la discovery ha fatto il suo lavoro: ha reso il progetto leggibile a qualunque team competente. Se ti risponde chiedendo di rifare una discovery sua, hai comprato materiale di vendita a tariffa da consulenza.

Quella prova risponde anche alla domanda sul prezzo. La discovery vale i soldi esattamente nel punto in cui il suo risultato sopravvive allo studio che l'ha prodotto.