Comprare e gestire software su misura

Comprare software su misura è una delle spese meno trasparenti che un’azienda affronti. Non vedi cosa compri finché non ce l’hai, i preventivi variano di dieci volte per “lo stesso lavoro”, e il momento in cui firmi è anche il momento in cui sai di meno. Il risultato è che tanti ci si fanno male: budget bruciati sul prototipo sbagliato, no-code che si blocca all’80%, progetti “finiti” che muoiono in sei mesi, fornitori che spariscono col codice sul loro PC. Questa guida raccoglie gli articoli che ti danno il metro: cosa stai davvero comprando, quando conviene costruire e quando comprare pronto, come non farti fregare, e cosa serve perché il software resti vivo dopo il lancio.

Il principio: il valore è nel 20% che il pronto non fa

Il filo che lega tutti gli articoli di questa guida è una sola idea, ripetuta da tante angolazioni: il pronto e il no-code ti portano all’80%, e il valore vero è nel 20% che non fanno. Quell’ultimo 20% è la tua logica specifica — il tuo modo di lavorare, le tue regole, i tuoi incastri — ed è esattamente la parte che decide se lo strumento cambia l’azienda o finisce in un cassetto. Comprare bene significa capire in quale dei due casi sei: se sei nell’80% standard, un SaaS pronto è la scelta intelligente e dirtelo fa parte del mestiere; se il tuo valore è in quel 20%, allora il su misura vale i soldi che vale.

L’altra idea che attraversa tutto è l’onestà sul costo nascosto: non quello scritto sul preventivo, ma quello di comprare male — l’inerzia misurata in euro, il progetto rifatto due volte, la prigione del fornitore. Ogni articolo mette in fila questi conti, perché la domanda giusta non è “quanto costa?”, ma “quanto mi costa comprare male?”.

Decidere se e cosa costruire

Prima di spendere un euro, la partita si gioca sul perimetro:

• «Ho un’idea di app e sto per firmare» — le 8 domande da rispondere prima di bruciare il budget sul prototipo sbagliato: cosa fare prima di sviluppare un’app.
• «Voglio un MVP, ma vero» — cosa si può davvero fare in 90 giorni, e cosa succede dopo il lancio: l’MVP in 90 giorni che non è una slide.
• «Il no-code mi si è bloccato» — quando e come chiamare chi costruisce, dopo che il pronto ti ha portato all’80%: i limiti del no-code in azienda.
• «Cosa c’è dentro un preventivo?» — la guida da compratore per leggere le voci, la proprietà, la manutenzione, e capire perché non è “un sito da 3.000 euro”: cosa include uno sviluppo su misura.

Il costo dell’inerzia: perché muoversi (e perché a volte no)

A volte il vero problema è restare fermi:

• «Quanto mi costa NON avere l’app?» — la stima in ore, errori e clienti persi che rende visibile un’emorragia invisibile: il costo di non digitalizzare i processi.
• «Ho speso decine di migliaia in un PoC di AI finito nel cassetto» — perché i prototipi muoiono e come non ripeterlo: il PoC di intelligenza artificiale fallito.
• «Il mio gestionale è un Access del 2008» — quando conviene riscrivere il legacy e quando no: riscrivere il software gestionale legacy.

I problemi operativi che spingono al su misura

Spesso il bisogno nasce da un dolore quotidiano concreto:

• «I commerciali hanno il pipeline in testa» — avere UN numero invece di tre versioni diverse della stessa realtà: la pipeline commerciale unica.
• «I lead arrivano e muoiono in 48 ore» — ti manca il cruscotto che li fa lavorare, non “più traffico”: i lead che non vengono lavorati.

Il rapporto col fornitore e il dopo-lancio

Comprare bene non è solo scegliere oggi: è restare liberi domani:

• «Il progetto “finito” muore in sei mesi» — manutenzione, chi ha le chiavi, e come non restare ostaggio di un fornitore che sparisce: la manutenzione dopo il go-live.
• «Devo rispondere a un RFI di 40 pagine» — come separare il requisito dal teatro e non firmare un suicidio (dal lato di chi vende): rispondere a un RFI software.
• «Il commerciale ha promesso una feature che non esiste» — come chiudere il buco tra vendite e prodotto prima che ti costi un cliente: la feature promessa che non c’è.
• «Vendo ore e ho toccato il tetto» — da consulenza a prodotto, per chi costruisce e non solo per chi compra: passare da consulenza a prodotto.

Perché una mano sola batte tre fornitori

C’è un motivo strutturale per cui i progetti su misura vanno male, e torna in quasi tutti gli articoli: vengono spezzati tra fornitori diversi — uno fa i dati, uno il backend, uno il frontend, uno “l’AI” — che quando qualcosa non torna si incolpano a vicenda. Tu, in mezzo, paghi in mesi e in nervi la mancanza di una regia. Il costo più grande di un software non è quasi mai la costruzione: è la cucitura tra pezzi pensati separatamente. Una mano sola che tiene insieme dati, backend, frontend e — dove serve — l’AI, non è più economica sul singolo pezzo, ma elimina il costo nascosto più grande, quello dell’insieme che non si incastra.

L’altro filo tecnico è il ruolo onesto dell’AI: assiste, prepara, trova, propone — non decide le cose che contano al posto di una persona, e non è affidabile dove un errore costa. Diffida di chi ti vende la magia; il valore sta nel prodotto solido attorno all’AI, non nella promessa.

Come usare questa guida

Parti dall’articolo che descrive il tuo dolore — non serve leggerli in ordine. Ognuno include il conto dell’inerzia in euro, cosa ottieni concretamente, la timeline onesta, la sezione “è per te se / non è per te se”, e l’onestà su quando ti basta un pronto — perché comprare bene, a volte, vuol dire non costruire affatto.

Quando vuoi ragionare sul tuo caso con qualcuno che parte dalle domande e non dal preventivo — e che conosce entrambi i lati del tavolo, chi compra e chi costruisce — il punto di partenza è il portfolio dei progetti o due righe in contatti.

Qui sotto trovi tutti gli articoli di questa guida.