Prima di consigliare a qualcuno di farsi sviluppare un software custom, bisogna dire una cosa che chi fa il nostro mestiere raramente dice ad alta voce: nella maggior parte dei casi, un software in scatola basta.

Il mercato italiano è pieno di gestionali, CRM, strumenti di fatturazione, software di settore che coprono dignitosamente il 70-80% delle esigenze di una PMI. Spesso costano poche migliaia di euro all'anno, sono aggiornati automaticamente, hanno documentazione, hanno una community. Sostituirli con un software custom perché "il nostro processo è speciale" è uno dei modi più comuni di bruciare soldi e tempo in un'azienda.

Detto questo — e proprio perché è vero quasi sempre — i casi in cui il custom è la scelta giusta esistono, sono riconoscibili, e quando ci sono, un software standard non li risolverà mai, per quanto costoso o personalizzabile sia.

Questo articolo prova a distinguere.

La domanda giusta

La domanda non è "il nostro processo è standard o custom?". Quasi tutti i processi aziendali sembrano speciali visti da dentro, e quasi tutti sono più simili alla media di quanto l'imprenditore creda. La domanda giusta è un'altra: esiste un software sul mercato che copre il mio processo, anche con qualche compromesso?

Se la risposta è sì, quasi sempre conviene adottarlo e adattare il processo dove serve. Se la risposta è no, e non è no per pigrizia della ricerca ma per una caratteristica strutturale del problema, allora si apre la strada del custom.

I tre segnali reali

Nei progetti di sviluppo che abbiamo portato a termine, i casi genuinamente da custom ricadevano in tre pattern ricorrenti.

1. Un processo verticale che il mercato non copre

Alcuni settori hanno processi troppo specifici per essere coperti da un gestionale orizzontale. Un canvas di progettazione per uno studio di interior design con vincoli particolari di rendering e misurazione, un flusso di controllo qualità in produzione con parametri che cambiano per ogni commessa, una logica di pricing dinamico che considera variabili fuori dallo standard ERP. Sono casi in cui il software di mercato, anche ampiamente configurato, non arriva al livello di precisione richiesto — e la distanza costa di più della realizzazione su misura.

2. L'accumulo di strumenti frammentati

Il secondo pattern è quello delle aziende che nel tempo hanno costruito il loro modo di lavorare incollando strumenti diversi: un gestionale legacy, un paio di fogli di calcolo condivisi, un'applicazione custom vecchia, un CRM cloud, un'automazione di mezzo fatta da un consulente che non c'è più. Funziona per inerzia, ma si rompe a ogni crescita, ogni nuovo collaboratore impiega settimane per capirlo, i dati sono disallineati tra i sistemi.

In casi come questo la riscrittura in un'unica applicazione moderna non è un upgrade tecnologico: è un intervento strutturale sulla produttività dell'azienda. Il software custom qui serve non tanto a risolvere un processo specifico, ma a restituire all'azienda una single source of truth operativa.

3. Il software come parte del prodotto o del servizio venduto

Il terzo pattern riguarda aziende per le quali il software non è un supporto interno ma un pezzo di quello che vendono al cliente finale. Una piattaforma di ticketing, una companion app di un prodotto fisico, un tool dato ai clienti come parte del servizio. Qui il custom non è un'opzione: il software è il prodotto, e comprarlo standard significherebbe vendere il prodotto di qualcun altro.

Cosa costa davvero il custom

Se dopo questa lettura pensi di rientrare in uno dei tre pattern, il passo successivo è capire cosa costa davvero. Un errore frequente è guardare solo il preventivo di sviluppo. Il costo reale di un software custom si compone di quattro voci:

  • Lo sviluppo iniziale. La parte più visibile, ma spesso non la maggiore su orizzonte pluriennale.
  • Il tempo interno durante lo sviluppo. Interviste, decisioni di design, test, formazione: chi in azienda conosce il processo deve dedicarci tempo, e quel tempo ha un costo opportunità reale.
  • Il post-go-live. Bug sottili, casi d'uso non previsti, piccole evoluzioni richieste dagli utenti reali. È la parte più sottovalutata, ed è anche quella in cui molti progetti falliscono (ne abbiamo scritto a parte).
  • Il cambio generazionale. Un software custom è un pezzo di infrastruttura aziendale che vive per anni. Chi lo manterrà tra cinque anni? Chi conosce il codice? Queste domande vanno fatte prima, non dopo.

In molti casi, questa somma rende il custom competitivo con l'off-the-shelf. In altri, no. Un buon partner di sviluppo ti aiuta a fare questo conto prima di firmare il contratto, non dopo.

Il modello ibrido

Esiste una terza opzione che ignoriamo troppo spesso: adottare un software di mercato e fare sopra un piccolo strato custom — integrazioni, automazioni, interfacce semplificate per usi specifici. È la scelta più ragionevole per aziende che hanno un processo mediamente standard con due o tre punti di specificità reale.

Un gestionale off-the-shelf con un'integrazione custom verso il sistema di produzione costa molto meno che un gestionale custom completo, e dà il 90% del beneficio. Quando ha senso, lo proponiamo noi stessi.

Come strutturare la decisione

Il modo più onesto di decidere tra custom e off-the-shelf è in tre passaggi, in quest'ordine.

Primo: fare una ricerca seria di mercato. Non "sentito dire da un conoscente", ma una valutazione strutturata di tre-cinque soluzioni concrete, con demo e almeno un test su un caso reale. La metà delle aziende che pensano di aver bisogno di custom, finita questa fase, scoprono che un software esistente va benissimo.

Secondo: quantificare il gap. Per le cose che il software di mercato non copre, quanto costa il gap? In ore di lavoro manuale, in dati persi, in errori ricorrenti, in clienti non serviti bene. Un gap da 2 ore al mese non giustifica un progetto custom. Un gap da 2 ore al giorno sì.

Terzo: parlare con qualcuno che non guadagna dalla risposta. Un partner di sviluppo onesto ti dirà "no, per quello che vi serve esiste X, non vi conviene fare custom" se è vero. Se ti dice sempre "sì è un progetto interessante, ecco il preventivo", stai parlando con chi ha interesse a vendere, non a risolvere.

Se pensi di rientrare nei casi reali da custom

Se la tua situazione rientra genuinamente in uno dei tre pattern descritti sopra, o vuoi semplicemente una seconda opinione prima di decidere, parliamone. La prima conversazione serve a capire insieme se quello che cerchi richiede davvero uno sviluppo custom, o se esiste un modo più leggero per arrivarci.

Scopri come lavoriamo sullo sviluppo software →

Fabio Gabelli è il founder di Revan SAS. Dal 2011 sviluppa software per PMI italiane e mantiene un portfolio di prodotti interni tra cui Ticketto, DorIAn e Universal Mapper.