Prodotto pronto o software su misura: quale scegliere e quando

Lei compra un CRM perché il responsabile vendite non ce la fa più con gli appunti, e dopo tre mesi accanto al sistema c’è un Excel con tre listini e una cartella di fatture che qualcuno ricopia in contabilità. Il prodotto non è peggiore di quello per cui è stato venduto, perché conosce il cliente, l’affare e la prossima chiamata, ma non conosce il Suo processo, perché questo processo non era quello che il produttore ha costruito per centinaia di aziende, e questo scarto è il tema di tutto l’articolo: se Lei compra uno strumento per il Suo processo, o un processo per il Suo strumento, non il buco in un elenco di funzioni che si può chiudere con un solo adattamento. Se il buco è un collegamento tra sistemi che già fanno il proprio lavoro, non è un argomento per costruire: prima colleghiamo ciò che già c’è.

Prodotto pronto o software su misura: quale scegliere e quando, non è una domanda su quale pulsante sembri più moderno, e non è nemmeno la domanda se Lei «sia abbastanza grande per costruire in proprio». La nostra risposta è la stessa che abbiamo scritto sulla pagina del servizio: se il Suo processo sta dentro uno strumento già pronto, prenda lo strumento pronto, costa meno, e un sistema su misura si giustifica quando il processo è parte del Suo vantaggio competitivo o quando le soluzioni pronte impongono troppi compromessi, e questa frase non è un trucco di vendita per poi venderLe comunque una costruzione, ma il test con cui perdiamo le righe in cui dovremmo scrivere un altro CRM, e teniamo quelle in cui il processo è parte del vantaggio o gli strumenti già pronti impongono troppi compromessi.

Questo articolo non è un confronto tra piattaforme di e-commerce, perché quello l’abbiamo già scritto altrove, e non è nemmeno il listino del software su misura, perché un articolo così non ce l’abbiamo e non l’avremo, perché i prezzi non ce li inventiamo, e non è nemmeno la promessa che un sistema proprio vinca sempre. Vendiamo sia l’implementazione di un prodotto pronto sia la costruzione da zero, e un testo onesto comincia dal fatto che a volte il servizio più caro che possiamo venderLe è quello di cui non ha bisogno, perciò più avanti sta il confine dopo il quale questa scelta si può fare, prima che qualcuno Le venda uno sprint.

Prodotto pronto o software su misura: quale scegliere e quando

Prenda il prodotto pronto se il processo ci sta dentro, e scelga il software su misura se il processo è il Suo vantaggio competitivo o gli strumenti già pronti impongono troppi compromessi: è tutta la risposta, e il resto di questo articolo è come verificare questa frase contro un lavoro concreto, non contro una presentazione. Un confronto che parte da una tabella di funzioni finisce prima di cominciare, perché la tabella mostra ciò che il produttore ha nominato, non chi fra un anno deciderà la Sua prossima modifica.

Le conseguenze del lato sbagliato non sono simmetriche, perché lo strumento già pronto in cui Lei ha infilato il proprio processo a forza diventa un abbonamento più Excel più una persona che tiene insieme i due, e questa persona dopo un anno costa più di qualsiasi licenza, mentre un sistema su misura per un processo che vive già in contabilità, nel programma di posta e in un CRM standard è una costruzione che manterrà Lei, anche se sul mercato la mantiene già qualcun altro. Nel primo caso ha comprato un prodotto e poi ha scritto un secondo sistema accanto, nel secondo ha scritto un sistema là dove bastava una licenza, e tutti e due gli errori costano più a lungo di quanto sembri nell’offerta.

Nominiamo questo confine perché abbiamo visto i due estremi nella stessa settimana: un’azienda che voleva «il proprio HubSpot» quando le serviva HubSpot, e un’azienda che per tre anni ha piegato un ERP pronto intorno alla propria tabella dei prezzi e alla fine è arrivata con quella stessa tabella come se fosse un progetto nuovo, non perché «l’ERP non sa farlo», ma perché i compromessi erano già più della configurazione. Nessuno di questi stati è frutto di cattiva volontà, perché entrambi partono dalla frase «ci serve un sistema», che non è ancora un test, e il test comincia soltanto quando Lei scrive il processo in una pagina sola senza il nome dello strumento e poi cerca quale strumento faccia già quella pagina.

Prima dell’acquisto scriva che cosa il sistema deve fare il primo giorno, che cosa non può dimenticare al secondo anno, e chi può cambiare quel secondo anno senza il rilascio di qualcun altro, perché se le risposte stanno in un prodotto che si può configurare, prenda il prodotto. Se la domanda è catalogo, prezzi, ordine e consegna in un e-commerce, quello è il test del negozio, e qui non lo riscriviamo; se le risposte sono un processo che il concorrente non può comprare come strumento già pronto, soltanto allora ha senso parlare di uno sprint. Questo articolo, da qui in poi, vende quest’ordine, non uno strumento.

Che cos’è il prodotto pronto e che cos’è il software su misura

Il prodotto pronto è un software che qualcuno ha già scritto per molti e che Lei acquista o sottoscrive per usarlo senza una ricostruzione sostanziale. Le Linee guida AgID sull’acquisizione e il riuso di software chiedono alla pubblica amministrazione una valutazione comparativa prima dell’acquisto, e di cercare prima le soluzioni già disponibili. COTS lo prendiamo qui come software commerciale pronto, che si può acquistare e usare senza adattamenti sostanziali, SaaS come un’applicazione disponibile su internet come servizio in abbonamento. Sono definizioni per la pianificazione, non un obbligo per un’impresa privata, e qui le prendiamo come parole già nominate, non come una legge che Le imponga un nulla osta della PA.

Il software su misura è un sistema scritto per il Suo processo, e in quelle stesse linee guida il software specializzato è un software sviluppato individualmente per le esigenze di un ente o di un settore. Lo chiamiamo anche sistema su misura, sulla pagina del servizio sistema non standard e nel titolo software su misura, e non sono tre prodotti, ma un solo lavoro: codice che parte dal Suo processo, non dal presupposto del produttore su che cosa sia un cliente, un ordine o una fattura, perciò la differenza non è «migliore» contro «peggiore», ma chi, dopo, può cambiare quel presupposto.

Il prodotto pronto non è una costruzione fallita, e una costruzione su misura non è un CRM migliore, perché WooCommerce è un prodotto e-commerce pronto, Moodle è una piattaforma di apprendimento pronta, WordPress è una piattaforma di contenuti pronta, e tutti e tre li vendiamo come implementazione, non come una costruzione nascosta sotto un altro nome. Laravel non è un prodotto in questo senso: è un framework su cui scriviamo sistemi su misura dalla versione 4.0 del 2013, e non dà un catalogo, un carrello o un CRM finché qualcuno non li ha scritti, perciò confondere il framework con il prodotto significa immaginare che «su Laravel» sia già una risposta, mentre è soltanto il modo in cui scrivere la risposta.

La terza cosa che di solito qui si confonde è l’abbonamento contro la proprietà, perché SaaS significa che Lei paga per l’uso e i dati stanno dal fornitore, una licenza perpetua significa che ha pagato il diritto di usare una versione e gli aggiornamenti sono spesso una riga a parte, mentre il codice su misura che noi consegniamo significa che il codice sorgente, la documentazione e la configurazione dell’infrastruttura sono Suoi. In nessuna di queste righe c’è una vittoria automatica, c’è soltanto chiarezza su che cosa sta comprando, perché altrimenti dopo un anno discute se «il sistema è nostro» quando in realtà è un abbonamento che si può interrompere.

Il test con cui facciamo questa scelta

Il test non è «se ci piace questa schermata», ma se il processo che Lei non può cedere a un concorrente sta in uno strumento che il concorrente può comprare nello stesso negozio: se ci sta, lo strumento è la risposta giusta, perché costa meno e lo manterrà qualcuno il cui unico lavoro è quello strumento, ma se non ci sta, perché la tabella dei prezzi, l’approvazione dell’ordine o le regole di consegna sono ciò con cui Lei si distingue, allora il prodotto pronto diventa un compromesso, e compromesso qui significa che il processo comincia a vivere in un Excel accanto al sistema.

L’altra faccia dello stesso test è troppo spesso dimenticata, perché i bisogni sono più spesso comuni che unici, e un programma di posta non si costruisce, una contabilità che già fa ciò che chiede la legge non si costruisce, e un imbuto di vendita standard in cui un affare è un affare non si costruisce. Le amministrazioni che spendono il proprio denaro secondo criteri scritti hanno nominato la stessa forma in un altro modo: prima chiedono se sul mercato la cosa già c’è, e costruiscono quando i prodotti disponibili non coprono il nucleo o quando la cosa va governata da sé, e questo non è un obbligo per un’impresa privata, e noi non lo trasformiamo in un obbligo del genere, ma è la stessa forma con cui diciamo no a una costruzione che si può comprare.

Il terzo errore è ricostruire il prodotto finché non è più un prodotto, perché la configurazione resta entro i limiti supportati (campi, ruoli, flussi che il produttore ha previsto), mentre l’adattamento che riscrive il nucleo perché il processo «finalmente ci stia» spende proprio il vantaggio per cui il prodotto era stato comprato: gli aggiornamenti, la documentazione, il fatto che l’errore lo trova qualcun altro. Lo abbiamo visto nelle implementazioni Moodle, dove prima controlliamo se il plugin esiste già e soltanto allora ne scriviamo uno nostro, e nei siti WordPress, dove un tema pronto non lo mettiamo, perché porta decine di funzioni che non Le servono e che diventano un rischio per la sicurezza, perciò un prodotto con un nucleo estraneo non è un sistema su misura, ma un prodotto al quale Lei ha tolto il nucleo del produttore.

Questo test lo facciamo nel workshop di discovery, non nella slide dell’offerta, perché nella slide vince sempre la costruzione che ha l’aria di prendersi cura di Lei, mentre nel workshop vince il processo che si può nominare. Se dopo due giorni risulta che il processo sta in uno strumento già pronto, lo diciamo, anche se significa che l’affare di questa settimana non è il nostro sistema non standard, perché un articolo che finisce sempre con «Le costruiremo il Suo» non è un test, ma un’offerta che si nasconde dietro una domanda.

Quando il prodotto pronto è la risposta giusta

Il prodotto pronto è la risposta giusta là dove il processo ha già un nome nel settore e Lei non è chi ha inventato quel nome, perché la posta, una contabilità che emette la fattura come chiede la legge, un CRM di vendita standard, una piattaforma di apprendimento che registra il corso e il completamento, e un negozio piccolo con un solo prezzo e un solo magazzino sono i posti in cui una costruzione non dà nulla per cui valga la pena pagare la differenza tra una licenza e uno sprint. Queste righe non le vendiamo come «soluzione temporanea, finché Lei non sarà pronto per il sistema vero», perché sono i sistemi veri per questi processi.

Questi prodotti li vendiamo anche noi, e non è una promessa nascosta che dopo un anno arriverà la costruzione: WordPress resta una piattaforma di contenuti con un tema che scriviamo noi, non con un tema pronto del negozio; per un negozio piccolo con processi standard lo diciamo noi stessi, WooCommerce; Moodle resta una piattaforma di apprendimento che configuriamo, migriamo e personalizziamo graficamente, non inventiamo da capo. I prezzi di queste righe stanno sulle pagine dei servizi e in un punto più sotto in questo articolo, dove serve mostrare che la soglia del su misura non è automaticamente la riga più cara, e qui basta dire che il prodotto resta prodotto.

Le conseguenze, se in questo punto ordina comunque una costruzione, non sono «un controllo migliore», ma una manutenzione che non divide più con migliaia di altri, perché la patch di sicurezza del programma di posta la rilascia qualcuno per tutti, mentre la patch del Suo programma di posta la rilascia Lei, e suona come libertà finché non arriva la seconda notte in cui deve riparare ciò che il produttore ha già riparato nel proprio prodotto. Questa libertà la vendiamo là dove il processo la merita, non là dove basta una licenza, perché altrimenti Le vendiamo un lavoro che dopo un anno odierà come un duplicato costoso.

Perciò la cosa più onesta che possiamo dire prima di qualsiasi preventivo non standard è un elenco di prodotti che Le consiglieremmo invece: se il processo è formazione, cominci da Moodle, se il processo è contenuti, cominci da WordPress, se il processo è un negozio piccolo, cominci da WooCommerce, e se il processo è fatture e la contabilità che la legge impone, cominci dalla contabilità che ha già, e soltanto allora si chieda se qualcosa di tutto questo debba diventare un sistema proprio. Questo elenco non è un contratto di partnership, è un test che usiamo contro noi stessi.

Quando il software su misura si giustifica

Il software su misura si giustifica quando il processo è parte del Suo vantaggio competitivo o le soluzioni pronte impongono troppi compromessi, e il processo può restare un supporto alla merce e essere comunque parte di questo test, perché il test è il numero dei compromessi, non se Lei vende software. Se il prodotto pronto comincia a chiederLe di diventare il cliente medio, e il cliente medio non è il Suo vantaggio, la costruzione è finalmente un test che il processo ha superato, non il desiderio di una schermata propria.

L’integrazione qui non è un argomento da sola, perché anche i prodotti hanno interfacce, e noi le colleghiamo, e l’argomento comincia soltanto quando l’interfaccia non basta e il processo esige che la verità su giacenza, prezzo o stato viva in un solo posto che Lei controlla. Il portale delle mappe di Sadales tīkls, che abbiamo costruito su Laravel e Leaflet, mostra i distacchi, la capacità libera e il costo di allaccio, e non è «una mappa più un plugin», perché costo e capacità sono il processo dell’operatore, non un campo del prodotto cartografico; nel portale Elektrum la sessione SSO si aggiunge a ogni richiesta prima che il configuratore Vue disegni, e non è «un tema energetico su WordPress», perché la sessione è parte del servizio, non un decoro.

Il colore, il logo e l’ordine del menu non sono questo test, perché si possono fare nel prodotto, e li facciamo nel prodotto: un tema Moodle con la Sua palette, un tema WordPress senza il superfluo, un negozio WooCommerce che ha il Suo aspetto. Se l’unica cosa che lo strumento già pronto non sa fare è «che assomigli a noi», Lei non è arrivato al software su misura, ma a un tema, e confondere le due cose significa pagare una costruzione là dove basta un disegno, e poi meravigliarsi che la manutenzione sia cara per un sistema la cui unica differenza è il colore.

Non diciamo nemmeno che ogni settore pretenda automaticamente una piattaforma propria, perché il nome del settore non è un test, e il test è se il processo di quel settore, nella Sua azienda, è lo stesso che il produttore ha già messo nel pacchetto, o è il Suo modo di far lavorare il settore, e questo modo non si può comprare accanto. Se si può comprare, compri; se non si può, allora si parla di sistemi aziendali su misura, e soltanto allora vale la pena parlare di un workshop di discovery, non di un tema.

La terza via: un prodotto con sopra il nostro codice

Tra il prodotto pronto e la costruzione da zero c’è una terza via, che vendiamo anche noi e che i confronti saltano più spesso: il prodotto resta prodotto, e sopra scriviamo ciò che il prodotto non fa, e non è «un po’ di software su misura», ma la decisione di lasciare il nucleo là dove lo mantiene il produttore, e scrivere soltanto lo strato che è Suo. Il portale dei servizi di Sadales tīkls sta su October CMS, e i calcolatori, i calendari e la segnalazione di un guasto sono lavoro sul prodotto, non un nuovo motore di contenuti; in un’implementazione Moodle prima controlliamo se il plugin di valutazione o di report esiste già, e soltanto allora ne scriviamo uno nostro, perché altrimenti Le venderemmo un duplicato.

Se la domanda è catalogo, prezzi, ordine e consegna, quello è il test del negozio, e sta già scritto nell’articolo sulla scelta tra WooCommerce e Laravel, perciò qui non lo riscriviamo e non lo trasformiamo nel default di un sistema non standard. Se la domanda riguarda un CRM, un ERP, un pannello interno o un processo di settore, resti qui, perché il negozio è un caso dello stesso test, non il contenuto di tutta la scelta.

Dal lato WordPress la terza via ha l’aria di un rifiuto, perché i temi pronti non li mettiamo, portano funzioni che diventano un rischio per la sicurezza, e costruiamo un tema pulito soltanto con ciò che serve, e questo resta un prodotto: il redattore scrive in WordPress, non in un editor che abbiamo inventato noi, e gli aggiornamenti arrivano da WordPress, non da un nostro rilascio soltanto. La differenza tra questo e un sistema su misura è che il processo dei contenuti sta nel prodotto, mentre il processo del tema non sta in un tema di ThemeForest, e confonderli significa o mettere un tema estraneo e poi meravigliarsi dei plugin, oppure costruire un CMS proprio per dei contenuti per i quali un CMS esiste già.

Questo confine è anche il punto in cui diciamo no a una «piccola ricostruzione» che al terzo mese è già il nucleo, perché se gli adattamenti diventano più della configurazione, se ogni aggiornamento chiede prima il nostro codice, se il campo del produttore non è più la verità, Lei non è più sulla terza via. È su una costruzione che si nasconde dietro il nome del prodotto, e allora è più onesto nominare la costruzione e fatturarla come costruzione, perché altrimenti paga un prodotto che non si può più aggiornare e un sistema che non si può ancora portare altrove.

Denaro e tempo sono una forma, non un listino

Un sistema su misura da noi parte da 8.000 €, e il ciclo completo di solito richiede da 12 a 32 settimane, ed è un «a partire da», non una fattura, e 12 settimane non sono gli stessi primi tre mesi in cui promettiamo un MVP utilizzabile: la soglia è la costruzione più corta, l’MVP è il passo dopo il quale il sistema si usa già, e 32 settimane sono il limite superiore di un lavoro più grande, che entra anche in ciò che nelle FAQ generali chiamiamo da sei a otto mesi per un grande sistema su misura. La pagina Laravel parte dalla stessa soglia di 8.000 € e da 6–24 settimane, e non è un software su misura più economico: è la pagina per chi sa già che il lavoro è Laravel, non il test se il lavoro sia proprio una costruzione.

Queste cifre non devono diventare la frase «il software su misura è la scelta più cara», perché un’implementazione Moodle parte da 15.000 €, la versione Pro del negozio costa 9.500 €, e tutte e due stanno sopra la soglia del su misura, perché una è l’implementazione di un prodotto grande, l’altra è un negozio con magazzino e prezzi B2B. Confrontare la soglia di 8.000 € con quella di Moodle come «costruzione contro prodotto» è un’aritmetica sbagliata, perché si possono confrontare soltanto due vie dello stesso processo, e anche allora entrambe le parti sono soglie, non totali; per i lavori non standard più grandi fatturiamo a tempo e materiali con un tetto settimanale, perché un prezzo fisso lì di solito significa un sovrapprezzo per il rischio o una lite sul perimetro, e la tariffa oraria è 50 €.

Nemmeno l’abbonamento contro la costruzione è una formula in cui dopo N anni una parte vince da sola, e la pianificazione della spesa pubblica nomina ciò che vediamo anche nei contratti privati: il canone SaaS può salire con il numero degli utenti o con l’indicizzazione, le integrazioni restano un Suo costo, e per cambiare fornitore serve un piano di uscita, perché i dati stanno da lui. Non è una percentuale della costruzione che citeremmo qui, perché la nota a piè di pagina dietro quelle cifre porta a blog di fornitori, e cifre così non le scriviamo, ma la forma resta: l’abbonamento è una riga ogni anno, la costruzione è una soglia più la manutenzione, e nessuna delle due è senza riga.

Il regolamento sui dati, applicabile nell’Unione dal 12 settembre 2025, aiuta a estrarre i dati esportabili da un servizio in cloud e vieta al fornitore di frapporre ostacoli al cambio, ma l’equivalenza funzionale la chiede a un servizio di infrastruttura, non a un CRM che Lei semplicemente «porta», e il regolamento 2023/2854 non promette che il processo si sposti insieme al file. L’articolo 20 del Regolamento generale sulla protezione dei dati porta i dati personali che l’interessato ha fornito, non l’applicazione, non la Sua configurazione, non le regole aziendali, perciò se vuole un sistema che possa portare a un altro sviluppatore, è il codice sorgente che noi consegniamo, non un’esportazione da un pannello altrui, e qui finisce anche questa sezione, perché la frase successiva sarebbe già un listino, e per questa domanda non ce l’abbiamo.

Che cosa non diciamo quando parliamo di software su misura

Non diciamo che un sistema proprio sia sempre più intelligente, che il prodotto pronto sia per chi «non è ancora cresciuto», o che dopo tre anni la costruzione si sia certamente ripagata, perché una curva così, senza il Suo processo, è un’invenzione. Un articolo che dopo un inizio onesto arriva comunque a dire che bisogna comprare la costruzione è andato troppo in là, e lo abbiamo visto abbastanza spesso da fermarci qui, perché l’onestà è un limite e un test breve è l’obiettivo.

Non diciamo nemmeno che Laravel sia la risposta alla domanda sul prodotto pronto, perché Laravel è il modo in cui scriviamo quando il test ha già dato una costruzione, e vendere un framework a chi ha bisogno di Moodle significa vendere un martello a chi ha bisogno di uno scaffale. La nostra pagina Laravel parte da 8.000 € e parla di API, code e test, ma questo articolo chiede se quella pagina Le serva proprio, e confonderle significa scegliere lo strumento prima di aver scelto il lavoro.

Non diciamo nemmeno che il workshop di discovery sia un modo nascosto per condurLa in una costruzione, perché il risultato del workshop è un piano che resta utile anche se decide di non lavorare con noi, e a volte il piano dice: prenda il prodotto che ha già nominato, e lo implementeremo noi, oppure lo implementerà qualcun altro. Se questa frase Le suona come un affare perso, è perché è un affare perso, e preferiamo perdere una costruzione in cui dovremmo scrivere un altro CRM piuttosto che ottenere un cliente che dopo un anno chiede perché mantiene un sistema che poteva prendere in abbonamento.

Per un appalto pubblico questo test non funziona come per un’impresa privata, e quella regola non si trasferisce, perché nella pianificazione dello Stato le Linee guida AgID chiedono di valutare se esista già una soluzione disponibile, e appartiene all’appalto, non a questa frase, mentre dal lato privato appartengono il Suo processo e il nostro listino. Le due parti possono arrivare alla stessa risposta, e non ci arrivano perché una sarebbe la legge dell’altra.

Come si prende questa decisione da noi

Il lavoro comincia con un workshop di discovery di 2–3 giorni, in cui insieme al Suo team parliamo dei processi, dei ruoli utente, dei rischi e del perimetro dell’MVP, e non è una mattina di slide, ma un lavoro dopo il quale possiamo dire se il processo sta in uno strumento già pronto, se chiede la terza via, o se è una costruzione. Se la risposta è un prodotto, il workshop si è ripagato con questa frase; se la risposta è una costruzione, il passo successivo non è il codice.

Prima del codice di produzione, in 2–3 settimane prepariamo un prototipo navigabile, perché lì cambiare idea costa meno che in un sistema pronto, e il prototipo non è «per avere qualcosa da mostrare al consiglio», ma il posto in cui Lei vede che la tabella dei prezzi che ieri ha nominato è in realtà un’altra tabella, e in cui questa scoperta costa giorni, non mesi. Soltanto dopo comincia lo sviluppo: nei primi tre mesi costruiamo un MVP che si può usare davvero, e poi allarghiamo in modo iterativo, in sprint di due settimane con una dimostrazione alla fine di ciascuno.

Alla fine riceve il codice sorgente, la documentazione e la configurazione dell’infrastruttura e può portarli a un altro sviluppatore, e non è la promessa che il trasferimento sarà piacevole, ma la promessa che non è vincolato al nostro account. Nei progetti più grandi restiamo sul tempo e materiali con un tetto settimanale, e il confine dell’MVP lo fissiamo comunque, perché altrimenti «agile» diventa una parola dietro cui sparisce il perimetro, e se dopo il workshop prende un’altra strada, il piano resta a Lei, come abbiamo scritto sulla pagina del servizio, e questo articolo non lo cambia.

Prima di scriverci, scriva il processo in una pagina sola senza il nome dello strumento e segni quali righe non può cedere al rilascio di qualcun altro: se la pagina è vuota o c’è soltanto «per avere un sistema proprio», Le serve un prodotto, e glielo diremo, ma se nella pagina c’è un processo che il concorrente non può comprare come strumento già pronto, allora vale la pena parlare di una costruzione. Ci scriva se vuole che leggiamo questa pagina insieme a Lei e Le diciamo quale lato Le appartiene, anche se la risposta è prendere il prodotto che ha già nominato.