Abbonamento o software tuo: quando il canone smette di convenire

La domanda arriva quasi sempre dopo la terza fattura. Sto pagando quattrocento euro al mese per un gestionale che uso a metà: non conviene farsene uno nostro? Detta in generale: meglio un abbonamento o un software tuo?

Dipende, e il modo in cui di solito si risponde a questa domanda è sbagliato in tutti e due i sensi. C'è chi dice sempre di sì, perché vende sviluppo. E c'è chi dice sempre di no, citando la manutenzione come se fosse una maledizione.

Noi facciamo tutt'e due le cose — hoopit, che abbiamo sviluppato, è a tutti gli effetti un software in abbonamento — e proprio per questo la risposta ci interessa meno del conto che la determina.

Cosa compri davvero con un canone

Prima di dire che il canone è denaro perso, vale la pena elencare cosa copre, perché è più roba di quanto sembri.

Copre gli aggiornamenti di sicurezza, che qualcuno deve fare e che nel software fatto in casa sono la prima cosa che si smette di fare. Copre i server e il fatto che funzionino anche il 15 agosto. Copre l'adeguamento alle norme che cambiano — fatturazione elettronica, scontrino telematico, regole sui pagamenti — che è lavoro puro e che con un canone non ti riguarda. E copre qualcuno da chiamare quando alle sette di sera non si stampa un documento.

Chi confronta un canone annuo con il preventivo di sviluppo sta confrontando due numeri che non misurano la stessa cosa. Sarebbe come paragonare il noleggio di un furgone al prezzo d'acquisto, senza contare il bollo, l'assicurazione e il meccanico.

I tre momenti in cui il conto cambia

Il canone smette di convenire in tre situazioni, ed è utile riconoscerle perché arrivano in quest'ordine.

Il prezzo cresce con una cosa che non c'entra col valore. Quasi tutti i listini sono per postazione. Se assumi cinque persone in magazzino che usano il software per battere un codice, paghi cinque licenze piene per una funzione sola. Da lì in poi il costo cresce con l'organico, mentre il beneficio no.

Ti manca una cosa che non arriverà. L'hai chiesta, hai ricevuto un «lo passiamo al team di prodotto», e sono passati due anni. È normale: il fornitore fa le cose che chiedono in mille, non quelle che chiedi tu. Il problema è che nel frattempo quella cosa la stai facendo a mano.

Il software ti costringe a lavorare in un modo che non è il tuo. È il sintomo più serio e il più difficile da mettere in numeri, perché non compare in nessuna fattura. Si vede dai fogli di calcolo che nascono attorno al gestionale per tenere le informazioni che il gestionale non prevede. Quando i fogli attorno diventano tre, il software vero sono i fogli.

Come si fa il conto

Su cinque anni, non su uno. E con quattro voci per parte.

Da una parte: canone × mesi × utenti previsti fra tre anni, più i moduli aggiuntivi, più le integrazioni che paghi comunque a qualcuno per far parlare quel software col resto, più il tempo delle persone speso nei passaggi manuali che quel software impone.

Dall'altra: lo sviluppo iniziale, più la manutenzione annuale — che è una percentuale reale, non zero — più l'hosting e i servizi di terze parti che userai comunque, più il costo di non avere nessuno da chiamare, che si copre con un contratto e quindi ha un prezzo.

Sul lato del canone tre voci sfuggono più delle altre. I moduli: la demo mostra tutto, il piano che compri no, quindi prima di confrontare scrivi quali funzioni ti servono davvero (automazioni, API, report, firma, ruoli) e controlla in quale piano vivono. Le integrazioni: se quelle native non esistono qualcuno deve costruirle, e a quel punto il canone resta standard ma il sistema intorno diventa su misura, con collegamenti che si rompono quando uno dei due sistemi cambia, come succede a ogni automazione.

La terza sono i passaggi a mano: esportare un CSV, copiarlo, pulirlo, ricaricarlo, aggiornare il foglio, mandare la mail. Non compaiono nella fattura del software, ma se dieci persone perdono mezz'ora al giorno perché il prodotto non segue il processo, il costo reale è molto diverso dal listino; quali di quei passaggi si possono togliere lo spieghiamo in quali processi automatizzare in azienda. Nel conto, poi, entrano anche formazione, supporto ed eventuale migrazione da una parte, monitoraggio ed evoluzioni dall'altra.

Fatto questo conto, succede spesso che il custom vinca. E succede altrettanto spesso che perda, e vada bene così: un abbonamento che ti sta stretto su una cosa che non ti distingue è un ottimo affare. La contabilità la fanno tutti nello stesso modo, e non è lì che si guadagna.

Due avvertenze su come si sbaglia questo conto, perché sono sempre le stesse.

La prima: si mette a confronto il canone di oggi con il preventivo di oggi, quando le due cose crescono in modo diverso. Il canone cresce con l'azienda — più persone, più sedi, più moduli — mentre lo sviluppo è grosso all'inizio e poi diventa manutenzione. Sono due curve, non due numeri, e si incrociano quasi sempre fra il secondo e il quarto anno.

La seconda: si dimentica il tempo. Un abbonamento è attivo domani mattina, una piattaforma tua arriva fra qualche mese. Se il problema è urgente, il canone vince anche quando sulla carta perde — e la scelta giusta diventa prendere l'abbonamento adesso e costruire con calma il pezzo che conta.

Il costo che nessuno mette a preventivo

Se decidi di costruire, c'è una cosa da mettere in conto sopra tutte le altre: il software non finisce.

Non è un cantiere che si chiude. È un impianto che si accende. Il browser cambia, il fornitore dei pagamenti aggiorna le sue regole, la libreria che usavi non viene più mantenuta, e una legge cambia il modo in cui vanno conservati certi dati. Nessuna di queste cose è un difetto di quello che hai costruito: sono tutte manutenzione ordinaria di qualcun altro che diventa lavoro tuo.

Un budget di sviluppo senza una voce di manutenzione annuale non è un budget ottimista, è un budget incompleto. E il modo più veloce di trasformare un investimento in un problema è metterlo in produzione e non guardarlo più per due anni.

La manutenzione va anche messa per iscritto prima del lancio, non dopo il primo guasto: chi aggiorna le dipendenze, chi riceve gli avvisi, in quanto tempo si risolve un bug, cosa è manutenzione e cosa è una funzione nuova, dove si prova una modifica prima di pubblicarla. Accanto serve un margine per evolvere, perché l'azienda cambia, fra un servizio nuovo, una sede nuova, un processo nuovo. Un software su misura senza quel margine rischia di diventare il prossimo sistema vecchio da cui scappare.

«Tanto resta un patrimonio» — vero, a certe condizioni

Si sente dire che un software di proprietà aumenta il valore dell'azienda. Può essere vero, ma non lo è per il fatto di esistere. Vale qualcosa a tre condizioni precise, e quando mancano vale zero anche se è costato molto.

Deve essere leggibile da qualcuno che non l'ha scritto. Codice ordinato, dipendenze normali, e da qualche parte scritto perché le cose sono fatte così. Un software che sa far funzionare una persona sola non è un patrimonio: è un rischio con la faccia di un patrimonio.

Devi averlo tu. Il codice, gli accessi ai server, i domini, i registri dei pacchetti. Capita più spesso di quanto si creda che l'azienda paghi lo sviluppo per anni e non abbia mai avuto in mano una copia di quello che ha pagato. E avere il codice non basta: se nessuno sa come si pubblica una modifica, come si aggiorna, come si controlla e come si ripristina dopo un guasto, il software resta nelle mani di chi l'ha costruito. Un progetto serio consegna anche documentazione, accessi, backup e procedure di rilascio.

Deve essere aggiornato. Un impianto fermo da tre anni non si riprende da dove l'hai lasciato: si riprende da un lavoro di rimessa in sicurezza che a volte costa quanto rifarlo.

Se le tre condizioni ci sono, allora sì, quel software è un bene aziendale — e in una trattativa lo si può mostrare. Se manca la prima, non è un bene: è un debito che paga chi arriva dopo.

Il vincolo che pesa più del prezzo

Le quattro domande da fare prima di firmare qualunque abbonamento non riguardano il prezzo. Riguardano l'uscita.

1. Come esporto i miei dati? Non «si può esportare», ma: in che formato, con dentro cosa, e ci sono anche gli allegati e lo storico?
2. Quanto costa esportarli? In alcuni contratti l'export completo è un servizio a pagamento, e il prezzo si scopre nel momento peggiore.
3. Esiste un accesso programmatico? Se c'è un'interfaccia per programmi, i tuoi dati sono raggiungibili senza chiedere il permesso ogni volta. Se non c'è, sei ospite a casa tua.
4. Cosa succede se chiudono? È raro e non è impossibile, ed è l'unico rischio del canone che non si copre con altri soldi.

Sulla terza conviene scendere nel dettaglio, perché un'interfaccia «disponibile» può comunque non coprire quello che serve: limiti di chiamate, costi, campi esposti, notifiche verso altri sistemi, permessi, versioni. Va verificata sul processo reale, non sulla scheda del prodotto.

Un fornitore che risponde bene a queste quattro domande è un fornitore da cui potresti andartene facilmente. Ed è esattamente per questo che è quello da cui conviene restare: chi non ti trattiene con i vincoli deve trattenerti con il prodotto.

Per lo stesso motivo la proprietà dei dati viene prima di quella del codice. Puoi usare un abbonamento per dieci anni senza problemi se puoi esportare tutto in modo completo, e puoi avere un software tuo e restare bloccato se i dati dipendono da un servizio esterno chiuso. Più il sistema diventa centrale, più il costo di uscita conta, anche se non hai nessuna intenzione di andartene.

La via di mezzo, che è quella che usiamo più spesso

Nella pratica quasi nessuno sceglie fra i due estremi, e chi lo fa di solito sbaglia.

La divisione che funziona è questa: abbonamento per tutto ciò che è uguale in ogni azienda, roba tua per il pezzo che ti fa guadagnare.

Contabilità, posta, firme, buste paga, backup: canone, senza discutere. Nessuno ha mai vinto un cliente perché la sua contabilità era originale.

Il pezzo dove il cliente ti incontra, invece — come si prenota, come si compra, cosa vede chi entra nell'area riservata — è quello che ti distingue, ed è lì che un modello standard ti fa somigliare a tutti gli altri. Se proprio quel punto è centrale nel servizio, vale la pena capire quando un'area riservata clienti crea davvero valore. Su Flow Porto Cervo i piani di abbonamento, le lezioni live con la replica e le gift card consegnate su WhatsApp non sono funzioni che si trovavano in un catalogo: sono il modo in cui quel lavoro guadagna.

I due mondi non sono in guerra. Il software tuo parla con i canoni che tieni, e chiedere che li sostituisca tutti è il modo più caro di cominciare.

Quando ha senso studiare il custom

Ci sono casi in cui non costruiremmo: processo standard, team piccolo, budget limitato, requisiti che cambiano di continuo, nessuno che possa seguire il prodotto, un software esistente che copre già il 90% di quello che serve. Lì comprare è quasi sempre la scelta più intelligente.

Cominciamo invece a studiare una piattaforma propria quando si sommano più segnali:

• il canone cresce più in fretta del beneficio, spesso perché crescono gli utenti;
• il processo è distintivo e determina margine e servizio;
• i workaround attorno al software sono diventati strutturali;
• le API del fornitore non bastano a collegare quello che serve;
• i dati sono strategici e non vuoi che restino chiusi altrove;
• la roadmap del fornitore non arriva dove ti serve;
• il volume è abbastanza alto da ripagare sviluppo e manutenzione.

Studiare non vuol dire costruire subito. Vuol dire fare una fase di analisi prima del preventivo finale: mappare processi, utenti, ruoli, dati, integrazioni, eccezioni e volumi. Senza questa fase un preventivo per un software su misura è un'ipotesi enorme. I segnali da osservare sono raccolti in quando serve davvero un gestionale su misura, mentre per capire il perimetro economico abbiamo messo in fila le voci in quanto costa un software su misura.

Costruire il pezzo che conta

Se il conto dice di costruire, il primo rilascio copre il processo centrale, quello da cui dipendono margine e servizio, e non la dashboard o il login; il resto può restare sull'abbonamento finché serve. Report avanzati, dashboard secondarie e personalizzazioni vengono dopo: così il budget resta leggibile e il sistema entra in uso prima.

Non tutto va scritto da zero. Autenticazione, pagamenti, email, archiviazione e analytics possono appoggiarsi a servizi affidabili, perché il vantaggio del software su misura è decidere il processo, non reinventare ogni pezzo di infrastruttura. Ruoli e permessi vanno invece progettati presto: amministratore, operatore, commerciale, partner, cliente, e per ognuno cosa vede. Un sistema che tratta tutti come amministratori è difficile da mettere in sicurezza dopo.

La sicurezza, del resto, non si deduce dal modello commerciale. Un abbonamento non è sicuro per definizione e un software tuo non è rischioso per definizione: nel primo contano fornitore, certificazioni, processi e accessi, nel secondo architettura, aggiornamenti, monitoraggio, backup e permessi. In entrambi i casi va verificata.

Un gestionale interno non ha bisogno di animazioni, ma deve essere veloce e chiaro, perché lo si usa ogni giorno: ricerca, stati, filtri, azioni, mobile se serve. L'interfaccia interna rende proprio perché moltiplica ogni operazione, e il valore del custom cresce con il volume: una funzione che fa risparmiare cinque minuti una volta al mese conta poco, la stessa funzione su mille operazioni cambia il conto.

Serve infine qualcuno, dentro l'azienda, che sappia perché il prodotto esiste, quali priorità ha e quali richieste meritano sviluppo. È il vantaggio principale del software tuo: invece di condividere la roadmap con migliaia di altri clienti, la priorità la decidi tu. È anche una responsabilità, perché ogni funzione nuova costa, e senza un responsabile di prodotto l'elenco delle richieste cresce e il software diventa una somma di desideri locali.

Migrare un pezzo alla volta

Il costo di migrazione va messo nel conto prima di decidere. Estrarre i dati, pulirli, mappare i campi, importare gli allegati, ricreare gli utenti e verificare lo storico può essere una parte importante del progetto, e cresce con gli anni passati sul vecchio sistema. Spesso serve prima una fase di pulizia fra duplicati, campi usati in modi diversi, note libere e allegati senza struttura: non è lavoro del nuovo software, è debito accumulato nel vecchio processo.

Per questo la migrazione graduale è spesso la scelta migliore. Invece di spegnere l'abbonamento il venerdì e accendere il software nuovo il lunedì, costruisci un modulo, lo sincronizzi con il sistema esistente, lo provi, ci sposti un team, verifichi e prosegui. Nel frattempo il nuovo modulo può leggere i dati dal vecchio software, così lo metti alla prova con dati reali senza chiedere all'azienda di cambiare tutto in un giorno. La convivenza temporanea costa, ma riduce molto il rischio.

Software interno e software venduto

hoopit non è un gestionale costruito per evitare un canone: è un prodotto SaaS, il software che l'azienda vende. Lì il custom non è un'alternativa all'abbonamento, è il business stesso, e cambiano anche le misure. Un SaaS venduto si giudica da attivazione, fidelizzazione, abbandoni, ricavi ricorrenti, uso delle funzioni e richieste di supporto, perché deve funzionare per molti clienti e non per un solo processo interno.

Un software interno può non essere venduto a nessuno: serve a ridurre lavoro, gestire dati, automatizzare e coordinare il team, e il suo ritorno nasce dall'operatività. Le sue misure sono il tempo per completare un'attività, gli errori, le richieste gestite, i tempi di risposta, gli utenti attivi e i passaggi eliminati. Metriche da startup, per un gestionale che non si vende, non servono.

Da dove partire

1. Prendi l'ultima fattura del gestionale e moltiplica per sessanta. Quello è il primo numero, e già da solo cambia parecchie conversazioni.
2. Conta i fogli di calcolo nati attorno a quel software. Sono la misura più onesta di quanto ti sta stretto.
3. Segna quali passaggi fai a mano perché il software non li prevede, e quanti minuti costano a settimana. Moltiplica anche quelli per cinque anni.
4. Se decidi di costruire, comincia dal pezzo che ti fa guadagnare, non da quello che ti dà più fastidio. Sono raramente lo stesso, e il primo si ripaga da solo mentre il secondo va solo pagato.

Quindi: conviene un abbonamento o un software tuo?

Compra tutto ciò che non ti distingue, costruisci solo dove controllo e differenza valgono abbastanza da sostenere sviluppo e manutenzione, e fai il conto su più anni, non sulla fattura di questo mese. Nessuna delle due strade vuol dire «pagare per sempre» o «possedere per sempre», perché tutte e due hanno costi ricorrenti. La scelta vera è quale parte del tuo vantaggio vuoi lasciare alla roadmap di qualcun altro e quale vuoi controllare direttamente.

Prima di firmare o di far partire lo sviluppo, chiedi due documenti: al fornitore dell'abbonamento un export completo dei tuoi dati, a chi dovrebbe costruire il software un piano di manutenzione su tre anni. Rendono il confronto concreto in un attimo. Il miglior software in abbonamento è quello da cui puoi uscire senza perdere il tuo patrimonio di informazioni; il miglior software proprietario è quello che può mantenere anche qualcuno diverso da chi l'ha scritto. In entrambi i casi conta la trasferibilità, più della proprietà.

Come impostiamo una piattaforma di proprietà — e quando invece diciamo di tenersi l'abbonamento — sta nella pagina app e sviluppo. Se il pezzo che ti fa guadagnare è la vendita online, c'è un discorso a parte in e-commerce. E se vuoi fare il conto sul tuo caso, portaci l'ultima fattura e i fogli di calcolo che ci girano attorno.