Costruire un piccolo tool su misura è diventato sorprendentemente accessibile. Ma accessibile non significa gratuito, sicuro o conveniente in ogni situazione. La competenza nuova non è soltanto saper costruire: è saper tracciare il confine.
Dalla ricerca del software alla descrizione del bisogno
Per anni, davanti a un problema operativo, il primo gesto è stato cercare un prodotto: confrontare piani, provare demo, adattare il proprio processo alle opzioni disponibili. Oggi, per strumenti circoscritti, può essere più rapido descrivere il bisogno a un agente di coding e assemblare una soluzione su misura.
È un cambiamento importante. Si abbassa il costo di composizione e aumenta il numero di persone che possono trasformare una necessità in software. Un generatore di documenti, una dashboard interna, un convertitore o una piccola interfaccia su dati esistenti possono nascere in ore, non in settimane.
Nel mio articolo “Quanto costa, davvero, non pagare più il software” ho ragionato sul prezzo dell’autonomia: un abbonamento viene scambiato con tempo, competenza e responsabilità. Qui voglio rendere quella scelta più operativa.
Non è una guerra tra comprare e costruire
Build vs buy viene spesso presentato come un bivio. Nella pratica è un continuum. Si può comprare un’infrastruttura e costruire l’interfaccia; collegare servizi esistenti con n8n; usare un modello tramite API senza inserirlo in ogni passaggio; sviluppare un tool locale per un compito e affidarsi a un SaaS per la parte critica.
La domanda utile non è “posso rifarlo?”. Quasi sempre, prima o poi, la risposta tecnica sarà sì. La domanda è se ciò che rende prezioso quel prodotto risiede nel codice visibile o nel sistema che lo circonda: affidabilità, aggiornamenti, assistenza, responsabilità, integrazioni, community e continuità.
Ricostruire una funzione è diverso dal sostituire un prodotto. Più il costo dell’errore cresce, più questa differenza diventa importante.
L’IA abbassa il costo della prima versione. Non elimina il costo di possedere ciò che abbiamo costruito.
I cinque limiti che emergono dopo la demo
La prima versione è la parte più visibile e, spesso, la più economica. I costi veri compaiono quando il tool entra nel lavoro quotidiano.
- Manutenzione: dipendenze, API e formati cambiano; qualcuno deve accorgersene e intervenire.
- Sicurezza: autenticazione, permessi, segreti e dati richiedono scelte che una demo può evitare.
- Affidabilità: errori, retry, backup, log e ripristino contano appena il processo dipende dal tool.
- Adozione: un’interfaccia costruita per chi l’ha pensata può restare incomprensibile agli altri.
- Responsabilità: quando l’output influenza clienti o decisioni, serve sapere chi approva e chi risponde.
Tenere il modello fuori dal ciclo quando non serve
Un altro limite è l’abitudine a inserire l’IA in ogni azione. Se il risultato può essere ottenuto generando una volta il codice e poi eseguendo una regola deterministica, il modello non deve necessariamente restare nel ciclo operativo.
Questa scelta riduce costi, latenza e variabilità. L’IA può aiutare a costruire l’artefatto, interpretare input non strutturati o gestire eccezioni; il software tradizionale può occuparsi dei passaggi stabili.
Un buon sistema ibrido non dimostra quanta IA contiene. Usa l’IA soltanto dove l’incertezza richiede linguaggio, classificazione o ragionamento, e conserva controlli espliciti nei punti critici.
Un test prima di costruire
Prima di autoprodurre uno strumento, provo a rispondere a sei domande. Non danno una formula matematica, ma rendono visibile il debito che stiamo scegliendo.
- Il problema è specifico abbastanza da giustificare una soluzione su misura?
- Esiste già un prodotto affidabile il cui costo è inferiore al tempo di manutenzione?
- Qual è il danno possibile se il tool smette di funzionare o sbaglia?
- Quali dati attraversa e chi può accedervi?
- Chi lo manterrà tra sei mesi, anche se chi lo ha creato non è disponibile?
- Possiamo costruire un primo nucleo reversibile, esportabile e senza dipendenze inutili?
L’autonomia è una scelta di responsabilità
Mi interessa l’idea di software personale perché restituisce alle persone la possibilità di piegare uno strumento al proprio lavoro. È una forma di autonomia concreta, soprattutto quando elimina passaggi inutili o permette a un team di conservare i propri dati e il proprio metodo.
Ma l’autonomia non coincide con il rifiuto del software commerciale. Significa poter scegliere con lucidità dove comprare affidabilità, dove assemblare componenti e dove costruire qualcosa che prima non esisteva.
L’arte non è produrre tutto da soli. È costruire il minimo strumento capace di restituire controllo, e fermarsi prima che quel controllo si trasformi in un nuovo lavoro invisibile.