www.scriptcasecommunity.it

Quanto costa un software? Il problema che mi tormenta da quarant'anni (e una proposta a mattoncini)

C'è una domanda che mi porto dietro da quando ho iniziato a scrivere codice sui mainframe IBM, alla fine degli anni Settanta: quanto costa davvero un programma? Non quanto lo si vende, non quanto lo si preventiva sperando di non sbagliare — quanto vale il lavoro che c'è dentro, e come lo si misura in modo che abbia un senso sia per chi lo scrive sia per chi lo paga.

Chi fa questo mestiere da abbastanza tempo ha visto passare almeno tre epoche di risposte a questa domanda. E nessuna, a mio parere, ha davvero funzionato.

Le epoche del "come si conta"

Prima epoca: la riga di codice. Anni fa si pagava a righe. Ogni programma aveva un prezzo commisurato al numero di istruzioni, con — e qui c'è già la prima crepa — un valore diverso tra la riga di istruzione e la riga di commento. Il paradosso è evidente a chiunque abbia programmato sul serio: la riga di codice premia la prolissità e punisce l'eleganza. Il programmatore bravo, quello che risolve lo stesso problema con metà del codice, guadagnava meno. Si misurava il peso del prodotto, non il suo valore.

Seconda epoca: il tempo. Poi si è passati al tempo: tante ore, tanto costo. Più onesto in linea di principio, ma il calcolo resta difficile. Quanto ci metto io con quarant'anni di esperienza e un framework che conosco a memoria non è quanto ci mette un altro — e non è giusto che il cliente paghi la mia lentezza né che io venga penalizzato per la mia velocità. Il tempo misura l'operatore, non l'opera.

Terza epoca: la preventivazione a stima. E qui il problema si fa ancora più spinoso, indipendentemente dal livello di analisi che riesci a fare. Preventivare un software significa mettere un prezzo su qualcosa che, per definizione, non esiste ancora. Chi lavora ad Agile lo sa bene: il preventivo totale "quanto costa finire tutto" è di fatto impossibile senza requisiti congelati, e i requisiti non si congelano mai. Così si oscilla tra il preventivo gonfiato per prudenza e quello ottimistico che poi ti massacra i margini.

L'intuizione: il software è fatto di mattoncini

Sono sempre stato convinto di una cosa: un programma, uno script, altro non è che l'insieme di tanti micro-componenti opportunamente collegati. Tanti piccoli mattoncini Lego che si incastrano tra loro.

Una form di caricamento dati non è un blocco monolitico. È una struttura base — i campi standard — a cui si aggiungono, uno per uno, componenti che hanno ciascuno un peso e un valore ben identificabili:

• la validazione avanzata dei dati inseriti;
• i controlli di coerenza tra campi correlati;
• le verifiche in tempo reale contro un database esterno;
• i suggerimenti automatici durante la digitazione;
• il salvataggio temporaneo automatico;
• il controllo di duplicazione;
• l'upload documenti con preview e validazione di formato e dimensione.

Ognuno di questi è un mattoncino. Ognuno riflette una competenza precisa, non un numero di ore né un numero di righe. E allora la domanda diventa: perché non arrivare a una sorta di macro-listino costituito da micro-elementi?

Gli optional: lo stesso mattoncino, tante varianti

C'è però un secondo livello, che è quello che rende il metodo davvero interessante. Un mattoncino non è mai una cosa sola: ha i suoi optional, esattamente come un'automobile ha lo stesso telaio ma allestimenti diversi.

Prendiamo il mattoncino più banale che esista: un campo di un form. Nella sua versione nuda è quasi gratis. Ma quel campo può portarsi dietro:

• un supporto di aiuto contestuale (un tooltip, un help in linea, una descrizione a comparsa);
• una modifica visiva che richiama alcuni stati del contenuto — il campo che diventa rosso se il valore è fuori range, verde se validato, evidenziato se obbligatorio e vuoto;
• una validazione, che a sua volta può essere leggera (formato, lunghezza) o pesante (controllo incrociato su database, verifica di coerenza con altri campi, chiamata a un servizio esterno).

Lo stesso mattoncino "campo", quindi, non ha un prezzo: ha un prezzo base e una serie di optional che si sommano. È qui che il listino smette di essere una lista piatta e diventa un vero configuratore, dove il valore cresce con la competenza incorporata, non con le righe scritte.

Il paradosso dei framework

C'è però una riflessione che non posso tacere, e che tocca da vicino chiunque lavori con un framework — Scriptcase compreso. L'adozione dei framework ha portato un doppio effetto, e i due lati della medaglia vanno guardati insieme.

Da un lato hanno standardizzato e reso velocissimo lo sviluppo: quello che una volta richiedeva giorni di codice scritto a mano oggi si genera in poche ore, con qualità uniforme e meno errori. È un progresso innegabile.

Dall'altro, però, hanno abbassato e omogeneizzato il valore economico percepito, appiattendo proprio quelle differenze che con gli optional cercavamo di valorizzare. Se il framework ti dà "gratis" la validazione, l'evidenziazione visiva, il supporto di aiuto — se quegli optional sono ormai un checkbox nell'ambiente invece che il frutto visibile di una competenza — allora il cliente fatica a percepire che valgono qualcosa. Il mattoncino con tutti i suoi optional montati sembra costare quanto il mattoncino nudo, perché produrlo costa quasi uguale.

Ed è esattamente qui che il configuratore diventa non solo uno strumento di preventivo, ma un atto di riappropriazione del valore. Non conta che il framework abbia reso facile montare l'optional: conta che quell'optional fa qualcosa in più, protegge un dato in più, evita un errore in più. Il configuratore serve a rendere di nuovo visibile — e quindi remunerabile — una differenza che la velocità di sviluppo aveva reso invisibile. Il framework abbassa il costo di produzione; il configuratore difende il valore d'uso.

Un listino di esempio

Per rendere l'idea concreta, ecco come potrebbe apparire un frammento di listino. La chiave è tenere separato il prezzo base del mattoncino — che si paga una volta sola — dal prezzo di ogni optional, che è il puro incremento che quell'aggiunta comporta. Il totale di un componente è quindi la base più la somma degli optional scelti. I valori sono puramente esemplificativi — servono a mostrare il meccanismo, non a fare da tariffario:
Un esempio di lettura: un campo con aiuto contestuale e validazione leggera costa € 5 (base) + € 5 + € 15 = € 25. Lo stesso campo con validazione pesante al posto di quella leggera arriva a € 5 + € 5 + € 55 = € 65. Il cliente vede esattamente quanto pesa ogni scelta, e può ragionare — "la validazione pesante su questo campo mi serve davvero, o mi basta quella leggera?". Il preventivo diventa una conversazione, non una trattativa al buio.

In fase di preventivazione: funziona già

La bella notizia è che, in fase di preventivazione, costruire un metodo simile è del tutto fattibile. In fondo è ciò che facciamo istintivamente quando pensiamo a un prodotto: lo scomponiamo mentalmente nei suoi pezzi. Formalizzare quel processo — dare un valore a ogni mattoncino e alle sue varianti — trasforma un'intuizione in un listino.

I vantaggi sono concreti e li ho toccati con mano:

• Trasparenza. Il cliente capisce esattamente cosa sta comprando. Non un totale opaco, ma un elenco di funzioni.
• Personalizzazione. Può scegliere solo i controlli che gli servono davvero, e aggiungerne altri in fasi successive.
• Valorizzazione della competenza. Il prezzo riflette cosa fa quel componente, non quanto tempo ci ho messo io a scriverlo.
• Educazione del cliente. Che è forse la cosa più importante: gli fai capire perché la qualità del software ha un costo.

Da qui a immaginare pacchetti predefiniti — un "pacchetto sicurezza", un "pacchetto performance" — il passo è breve. E nel tempo si arriva a una vera libreria di componenti con listino associato, che rende più efficiente sia il preventivo sia lo sviluppo.

Il vero scoglio: la consuntivazione

Ma qui arriva l'onestà intellettuale. In fase di preventivazione il metodo a mattoncini è elegante. In fase di consuntivazione? Come rendo trasparente l'elenco reale dei mattoncini effettivamente montati, con le loro varianti, e come genero una sorta di distinta base — una vera bill of materials del software, come si fa in produzione industriale?

Questo è lo scoglio contro cui si infrangono i buoni propositi. Perché i normali ambienti di sviluppo non facilitano affatto questo aspetto. Nascono per automatizzare alcune fasi primarie della scrittura del codice, non per consuntivare il lavoro. Ti danno il cosa hai prodotto, non il di cosa è fatto in termini economicamente leggibili. E gli ambienti più evoluti, quelli che forse potrebbero aiutarti, sono spesso chiusi: non ti lasciano interrogare il loro interno.

Il preventivo resta così una promessa che il consuntivo non sa mai confermare o smentire con precisione. E senza consuntivo affidabile, il listino a mattoncini rischia di restare un bell'esercizio teorico.

Perché Scriptcase cambia le carte in tavola

Ed è qui che, nella mia esperienza, un ambiente come Scriptcase diventa interessante — non per marketing, ma per una ragione strutturale.

Scriptcase ha un suo ambiente interno, un repository che nasce per facilitare e uniformare lo sviluppo. Ogni applicazione è descritta, catalogata, resa omogenea. E un ambiente che uniforma lo sviluppo, per sua stessa natura, permette anche un'indagine di tipo "economico": se le applicazioni sono descritte in modo strutturato, quella struttura è interrogabile. Diventa possibile, almeno in linea di principio, risalire dai manufatti alla distinta dei mattoncini che li compongono.

Lo dico con la prudenza di chi ci sta ancora lavorando, non di chi ha la soluzione in tasca. Ma la direzione mi sembra quella giusta: usare la standardizzazione imposta dall'ambiente non solo per produrre più in fretta, ma per rendere finalmente misurabile ciò che si è prodotto. Il repository che serve a sviluppare in modo uniforme è lo stesso che può servire a consuntivare in modo trasparente.

Un esempio concreto: GERIM

Non parlo per astrazioni. Ho costruito nel tempo un sistema — oltre milleduecento applicazioni interdipendenti sviluppate in Scriptcase — e quando è arrivato il momento di metterci un valore sopra, mi sono trovato esattamente davanti a tutte le domande di questo articolo. Quanto vale? A righe? A tempo? A stima?

La risposta sensata non è stata nessuna delle tre in purezza. È stata ragionare per componenti e per valore di sostituzione: non quanto è costato scriverlo, ma quanto costerebbe rifarlo da zero. E un sistema fatto di tanti mattoncini specializzati — moduli di analisi, controlli antifrode, reportistica, logiche di compliance — mostra il suo valore proprio quando lo scomponi e ti accorgi di quanti pezzi distinti, ciascuno frutto di una competenza specifica, ci sono dentro. La distinta base del software non è solo uno strumento di prezzo: è uno strumento di consapevolezza, per te prima ancora che per il cliente.

In sintesi

Il problema di come misurare il costo del software non è risolto — probabilmente non lo sarà mai in modo definitivo, perché il software non è un manufatto fisico e ogni analogia industriale ha un limite. Ma la strada a mattoncini mi sembra la meno peggiore tra quelle percorse finora:

• supera la riga di codice, che premia la prolissità;
• supera il puro tempo, che misura l'operatore e non l'opera;
• rende il preventivo un elenco trasparente invece di un totale opaco;
• e — questa è la scommessa — apre la possibilità, dove l'ambiente di sviluppo lo consente, di consuntivare davvero, generando la distinta dei componenti realmente montati.

Non mi limito a teorizzarlo: sto realizzando un sistema di gestione di questo problema. Un sistema che parta dal listino a mattoncini e optional per il preventivo, e che — sfruttando la struttura interna dell'ambiente di sviluppo — provi a chiudere il cerchio anche sul consuntivo, generando la distinta reale dei componenti effettivamente montati. È un lavoro in corso, con tutti i limiti e i dubbi del caso, ma sono convinto che la strada sia percorribile.

E allora la domanda che vi giro è duplice. Qualcuno di voi ha già provato a costruire un listino a componenti — magari con optional, magari senza chiamarlo così — per il proprio lavoro? E soprattutto: qualcuno è riuscito a chiudere il cerchio dal lato della consuntivazione, a generare cioè una vera distinta base del software prodotto? Perché il preventivo a mattoncini, in un modo o nell'altro, lo facciamo quasi tutti. È il consuntivo trasparente il vero terreno inesplorato — ed è lì che mi piacerebbe confrontarmi con chi ci ha già messo le mani.


Rino

Senza un’analisi fatta bene, dal cliente o insieme allo sviluppatore, secondo me è molto difficile mettere a terra un preventivo serio. Il rischio è che quello che inizialmente sembra un progetto da X ore diventi tutt’altro durante lo sviluppo.

Io generalmente mi regolo in due modi.

1. Preventivo a progetto
Se il cliente mi fornisce un’analisi dettagliata di quello che vuole e per analisi intendo qualcosa di strutturato, non un semplice elenco di 'desiderata' riesco a fare un preventivo abbastanza preciso.
In questo caso stimo il lavoro e aggiungo normalmente un +10% di margine per le varie ed eventuali che inevitabilmente possono sorgere in corso d’opera.
Il vantaggio per il cliente è evidente: conosce in anticipo il costo finale.
Per lo sviluppatore può essere una soluzione molto conveniente, soprattutto quando nel progetto ci sono procedure, moduli o componenti già sviluppati e riutilizzabili con poche modifiche.
Il rischio è sempre quello di aver sottovalutato qualcosa in fase di preventivo e quindi di 'bagnarsi': il prezzo è stato concordato, ma le ore necessarie diventano molte più di quelle previste.

2. Tariffa oraria e fatturazione a consuntivo
Quando invece il cliente è in fase di startup, cioè sa più o meno dove vuole arrivare ma non ha ancora un’analisi precisa e magari ha soltanto un’idea che evolve man mano che vede il prodotto, preferisco lavorare a costo orario.
A fine mese fatturo semplicemente le ore effettivamente lavorate sul progetto.
La prima obiezione del cliente, comprensibilmente, è quasi sempre: 'Ma così non so quanto mi costa ogni mese.' e la supero proponendo un budget massimo mensile di ore fatturabili. Il cliente conosce quindi il suo impegno economico massimo e può metterlo a budget. All’interno di quelle ore può chiedere modifiche, nuove funzionalità, cambi di priorità, ecc.
Questo sistema, secondo me, funziona particolarmente bene nei progetti che devono crescere nel tempo e nei quali è praticamente impossibile sapere all’inizio cosa servirà tra sei mesi.
Naturalmente richiede un rapporto di fiducia tra cliente e sviluppatore. È spesso la prima obiezione che incontro, ma alla fine il concetto che cerco di far passare è molto semplice: 'Cosa posso fare, fatturarti tre o quattro ore in più al mese? Io non divento più ricco e tu non diventi più povero.'
Lo svantaggio del secondo metodo è soprattutto per lo sviluppatore: le ore sono finite. Più di un certo numero di ore al mese materialmente non si riescono a vendere. Con il prezzo a progetto, invece, se sei molto efficiente o riesci a riutilizzare parecchio codice, la marginalità può essere decisamente superiore.

Quale scegliere?

Dipende dal progetto e soprattutto dal cliente. Personalmente non ho una preferenza assoluta: utilizzo entrambi i sistemi a seconda della situazione.
Con il tempo, però, ho imparato che per me è ancora più importante la selezione dei clienti.

Preferisco averne meno, ma con una capacità di spesa non troppo risicata, in modo da poter lavorare con maggiore tranquillità e concentrarmi sulla qualità del progetto invece di dover discutere continuamente ogni singola ora o piccola modifica.
Questa selezione non è semplice e soprattutto richiede tempo. Richiede anche il coraggio di rinunciare a qualche lavoro.
A volte una piccola commessa sembra comunque un’opportunità da prendere, ma tra riunioni, telefonate, assistenza, richieste, amministrazione e continue micro-modifiche finisce per assorbire molte più energie rispetto agli introiti che genera.

Ciao Fabio,

vecchie abitudini, le uniche possibili quando non sei messo nelle condizioni di valutare il singolo mattone.

Tu ragioni su come preventivare — a progetto o a consuntivo, con la selezione del cliente come discriminante. Giusto. Ma io vorrei proporti un piano diverso, che sta a monte di entrambi i tuoi metodi e che secondo me li risolve tutti e due.

Partiamo da cosa è un programma: non un blocco monolitico, ma un insieme di mattoncini incastrati. E ogni mattoncino non ha un prezzo solo — ha una base e i suoi optional, esattamente come un'auto ha lo stesso telaio e allestimenti diversi. Un campo nudo è quasi gratis; lo stesso campo con validazione pesante — pensa alla partita IVA verificata in tempo reale contro l'Agenzia delle Entrate — vale tutt'altra cifra. Se costruisci un listino così, il preventivo smette di essere una stima al buio e diventa un configuratore: sommi componenti di cui conosci già il peso.

Questo, da solo, ti toglie il rischio di "bagnarti" nel preventivo a progetto. Ma il vero terreno inesplorato è l'altro: la consuntivazione. Perché il preventivo a mattoncini lo facciamo un po' tutti, istintivamente. Quello che nessun ambiente ti dà è la distinta reale dei mattoncini che hai effettivamente montato a fine lavoro — la bill of materials del software, come in produzione industriale.

Ed è qui che Scriptcase diventa complice. Non per marketing: per una ragione strutturale. Ogni azione di ogni script vive dentro il suo repository, descritta e catalogata in modo uniforme. E un ambiente che uniforma lo sviluppo, per sua stessa natura, è anche interrogabile: se le applicazioni sono descritte in modo strutturato, quella struttura la puoi leggere e risalire dai manufatti alla distinta dei componenti. Il repository che serve a sviluppare in modo uniforme è lo stesso che può servire a consuntivare in modo trasparente.

Ecco il metodo che ti propongo: un listino a mattoncini e optional per il preventivo, e — sfruttando l'interno di Scriptcase — la generazione della distinta reale per il consuntivo. Chiudere il cerchio. Al cliente non dici più solo quante ore, ma cosa hai montato e quanto pesa ogni pezzo.

Non è solo il "cosa fa", ma anche il "come fa". Ci sto lavorando davvero — e mi piacerebbe capire se qualcuno ci ha già messo le mani dal lato del consuntivo, perché è lì che si gioca tutto.

Direi problema comune... anche io me lo chiedo da decenni. Una distinzione di base è stabilire separatamente i costi dal prezzo di vendita, per i costi la strada è in apparenza più semplice mentre per il prezzo le cose si complicano.
Un esempio concreto ho sviluppato un software LIMS e l'ho installato in diversi lab. ora in questa fase sto pensando alla vendita del "pacchetto" (parolone che che nella mia esperienza non si verifica mai ogni realtà ha necessità di personalizzazioni e/o aggiustamenti).
Io per brevità ho creato un modulo base e il vari add on, quindi modulo base, e poi le varie funzionalità preventivi, magazzino, fatturazione, interfacciamento strumenti....
Ma anche qua ci scontriamo con considerazioni non tecniche ma di marketing il laboratorio con tre dipendenti e due strumenti deve pagare lo stesso di uno con 15 dip. e 20 strumenti? quindi la logica dei mattoncini secondo te può funzionare? Comunque il tentativo è lodevole non so se potrai raggiungere una filosofia che racchiude in se tutte le varianti.
Ciao Sandro.

Sandrol ha scritto: 22 ago 2026, 09:16 Direi problema comune... anche io me lo chiedo da decenni. Una distinzione di base è stabilire separatamente i costi dal prezzo di vendita, per i costi la strada è in apparenza più semplice mentre per il prezzo le cose si complicano.
Un esempio concreto ho sviluppato un software LIMS e l'ho installato in diversi lab. ora in questa fase sto pensando alla vendita del "pacchetto" (parolone che che nella mia esperienza non si verifica mai ogni realtà ha necessità di personalizzazioni e/o aggiustamenti).
Io per brevità ho creato un modulo base e il vari add on, quindi modulo base, e poi le varie funzionalità preventivi, magazzino, fatturazione, interfacciamento strumenti....
Ma anche qua ci scontriamo con considerazioni non tecniche ma di marketing il laboratorio con tre dipendenti e due strumenti deve pagare lo stesso di uno con 15 dip. e 20 strumenti? quindi la logica dei mattoncini secondo te può funzionare? Comunque il tentativo è lodevole non so se potrai raggiungere una filosofia che racchiude in se tutte le varianti.
Ciao Sandro.

credo che il tuo sia un problema diverso ovvero su una scala diversa , molto più macro.
La vendita a licenza per numero utenti è una relativa novità , nasce più dal $Bill che da altri ma ha comunque un senso , in fondo più utenti più casini più assistenza più problemi.
In questo caso la stima è necessaria e questa non deve dimenticarsi dello strato di evoluzione del utilizzatore . Siamo però dentro un contesto di mantenimento ovvero legato alla rendita del prodotto realizzato.
Quanto voglio che mi renda e in quanto tempo?
Quanto voglio che le rogne siano compensate?
Io con questo mio lavoro sto concentrandomi sul costo/vendita specifico del prodotto e dei suoi micro componenti , quindi sono a livello di singola app ( per dirla alla sc) .
Un esempio , quel form è costituito da n campi video con n controlli suddivisi tra diretto i collegati agli eventi .
diretti sono quelli definibili direttamente da dentro il form che tratta il campo , gli altri dagli eventi .
In una griglia idem , per esempio i bottoni , le azioni nell evento onrecod (quanti link a varie tabelle?) o direttamente nel campo .
Le macro collegate alla enfatizzazione di un campo /riga.
Capisco che magari creare una if che modifichi il form dei campi possa essere questione di attimi ma è pur sempre un "oggetto" che ha il suo valore ed è evidenziabile in modo automatico ,quindi anche valutabile .
Anni fa ero vice capocentro in Jacobacci Casetta & Peyrani , eravamo leader nei marchi e brevetti , oggi soon una grande struttura legale a tutela dei diritti industriali . Mi è accaduto di averci a che fare come cliente e sono rimasto sconvolto dall elenco di attività che mi sono state presentate per il conto (ovviamente da ex era gratuito) , ecco erano presenti anche le voci : lettura email, analisi email, risposta , ecc. una distinta estremamente dettagliata, mancava solo : caffè di relax o tempo per prendere il libro con i riferimenti citati o tempo per cambiare la matita .... Sto parlando di un veloce scambio di pareri per una questione di dominii.
Quindi se un attività di puro pensiero può essere codificata e consuntivata perchè noi no?
Oggi abbiamo uno strumento comodo ma forse non la giusta forma mentale
Altro esempio : in ambito sanitario tutto è codificato , anche se voi non lo vedete esiste un profondo nomlencatore che identifica ogni cosa si fa sia in ambito infermieristico che chirurgico , ogni azione che sia una semplice igniezione , una medicazione o un intervento ( e qui le cose si complicano ma si arriva a contare persino la lunghezza dei fii di sutura ) è codificata , ma anche quanta garza utilizzata .
E ritorno alla domanda : e noi?
Insomma se metto le mani sula tastiera , se guardo il monitor, se cerco su un libro questi sono atti professionali , andrebbero valorizzati .
Non dimentichiamo che il nostro lavoro produce sempre reddito ,diretto o indiretto che sia .

Hai ragione non avevo capito il tuo obbiettivo, creare una struttura che tenga conto dell'insieme delle attività svolte x un progetto e/o cliente sarebbe il vaso di pandora. Il discorso è semplice chi tiene nota delle attività (ho scritto un evento per questo, ho inserito un if per quello.....) io personalmente non sempre ci riesco nel mondo reale tra telefonate ricevute e attività da portare a termine spesso e volentieri mi "perdo" e sto parlando di macro attività (rispetto al dettaglio che vuoi tu. Secondo me se trovi il modo di automatizzare il processo allora si altrimenti non saprei, io sono "certo" che a questo livello di dettaglio durerei forse un giorno. Se riesci ad automatizzare il processo hai fatto bingo.