Per creare uno strumento interno nel 2026 avete quattro strade: configurare un SaaS già pronto, assemblarlo in una piattaforma low-code, commissionare uno sviluppo su misura oppure generarlo con un creatore di app con IA. La strada conta meno di ciò che decidete prima di aprirne una: quale processo copre lo strumento, quali dati registra e chi può vedere cosa. I team che chiariscono questi tre punti mettono in produzione uno strumento funzionante in pochi giorni. Gli altri rifanno lo stesso foglio di calcolo con un'interfaccia più carina.
La questione non riguarda più soltanto i reparti di ingegneria. Nel report Build vs Buy 2026 di Retool, un sondaggio su 817 persone che sviluppano software in azienda, il 35% aveva già sostituito almeno un prodotto SaaS con uno strumento costruito in casa e il 78% prevedeva di costruirne di più quest'anno. Questa guida risponde alle domande che sorgono lungo il percorso: cosa si intende per strumento interno, quando un foglio di calcolo deve diventarlo, quale strada si adatta a quale team e come passare da un processo a uno strumento che i colleghi usano davvero.
Cos'è uno strumento interno? Esempi per team
Uno strumento interno è un software che un'azienda costruisce o configura per i propri dipendenti e non per i clienti: il back-office dietro il sito, la schermata in cui l'assistenza emette un rimborso, il tracker che l'ufficio operativo apre ogni mattina. Ha pochi utenti, spesso da cinque a duecento, ma questi utenti ci passano ore e al suo interno vivono regole che non esistono altrove: chi approva uno sconto, quando un ordine è in ritardo, quali campi sono obbligatori prima che una pratica proceda.
La maggior parte nasce allo stesso modo: come foglio di calcolo, casella condivisa o modulo cartaceo di cui qualcuno finisce per stancarsi.
| Strumento interno | Cosa sostituisce | Chi lo usa | Una prima versione sensata |
|---|---|---|---|
| Pannello di amministrazione o back-office | Modifiche dirette nel database, richieste agli sviluppatori | Assistenza, operations | Cercare, consultare e correggere le schede cliente |
| CRM su misura o pipeline commerciale | Un foglio condiviso più catene di email | Vendite, account manager | Contatti, trattative, fasi, prossima azione |
| Flusso di approvazione | Catene di email e PDF firmati | Responsabili, amministrazione | Modulo di richiesta, approvazione o rifiuto, storico |
| Gestione di magazzino o scorte | Un foglio che capisce una sola persona | Magazzino, acquisti | Articoli, movimenti, avvisi di scorta bassa |
| Dashboard operativa | Il report copia e incolla del lunedì | Responsabili di team, direzione | Cinque numeri che si aggiornano da soli |
| Tracker di cantiere o interventi | Moduli cartacei, foto in una chat di gruppo | Tecnici, pianificazione | Interventi, stato, foto, firme |
| Portale per clienti o partner | Email di aggiornamento e cartelle condivise | Clienti, fornitori | Login, i propri record, documenti |
Lo stesso sondaggio mostra da dove partono le aziende. Tra i team che hanno sostituito un prodotto SaaS, le categorie ricostruite più spesso in casa sono state le automazioni di flusso (35%), gli strumenti di amministrazione interni (33%), le dashboard di BI (29%) e i CRM e i form builder (25%). Il caso del CRM è così frequente che gli dedichiamo una guida a parte, su come creare un CRM personalizzato.
Quando un foglio di calcolo deve diventare uno strumento interno?
I fogli di calcolo sono lo strumento interno di maggior successo mai distribuito e nulla qui suggerisce di eliminarli tutti. I problemi cominciano quando un file diventa, senza che nessuno lo decida, il sistema di riferimento dei dati. La ricerca sugli errori nei fogli di calcolo di Ray Panko all'Università delle Hawaii, che raccoglie audit sul campo di fogli operativi, ha rilevato che l'88% dei 113 fogli verificati dal 1995 conteneva errori. Il tasso di errore per cella è basso. Il problema è che un file grande lo moltiplica e che in un foglio nulla blocca un valore sbagliato prima che qualcuno agisca sulla sua base.
Cinque segnali indicano che il file è andato oltre se stesso. Più di tre persone lo modificano, e compaiono versioni diverse e celle sovrascritte. Qualcuno non dovrebbe vedere tutte le righe, per esempio una colonna di stipendi o i clienti di un'altra regione, e l'unica protezione è una scheda nascosta. Una scheda contiene formule che nessuno osa toccare. Dovete sapere chi ha cambiato un valore e quando, e il file non sa dirlo. Oppure i dati vengono digitati di nuovo in un altro sistema, perché nulla collega i due. Un segnale è un fastidio. Due o più significano che il foglio svolge già il ruolo di strumento interno, senza le sue protezioni. In quel caso, la nostra guida su come trasformare un foglio di calcolo in un'app copre la migrazione passo dopo passo.
Costruire, comprare o generare: quattro modi per avere uno strumento interno
Costruire o comprare era una scelta a due. Le piattaforme low-code l'hanno resa a tre una decina di anni fa e i creatori di app con IA hanno aggiunto una quarta strada, in cui descrivete lo strumento e ricevete un'applicazione funzionante. Ecco come si confrontano i quattro approcci per uno strumento tipico con 20-50 utenti.
| Strada | Prima versione | Costo tipico | Chi lo costruisce | Cosa possedete | Ideale per |
|---|---|---|---|---|---|
| SaaS già pronto, configurato | Giorni | Abbonamento per utente, spesso da $10 a $50 per utente al mese | Un amministratore del team | Un'esportazione dei dati, non lo strumento | Processi standard: buste paga, helpdesk, contabilità |
| Piattaforma low-code (Retool, Appsmith, Budibase, Softr) | Da giorni a settimane | Per builder e per utente finale, ogni mese | Uno sviluppatore o un profilo tecnico delle operations | Il vostro database; l'app vive sulla piattaforma | Schermate sopra dati che avete già |
| Sviluppo su misura | Da 4 a 12 settimane per uno strumento mirato | Cinque cifre all'inizio, poi circa il 15-20% l'anno di manutenzione | Sviluppatori, interni o in agenzia | Tutto, manutenzione compresa | Strumenti che sono un vantaggio competitivo |
| Creatore di app con IA | Da ore a giorni | Un piano fisso da circa $20 al mese, a crediti e non a utenti | Chi conosce il processo | Codice sorgente e database, se lo strumento li esporta entrambi | Strumenti su misura quando non c'è uno sviluppatore |
I conti del prezzo per utente
Gli strumenti interni hanno una caratteristica scomoda per i prezzi: molti utenti occasionali. Nel listino pubblico di Retool a settembre 2026, il piano Team costa $10 per builder e $5 per utente interno al mese con fatturazione annuale, mentre audit log e controlli granulari sui permessi partono dal piano Business, a $50 per builder e $15 per utente interno. Per due builder e quaranta colleghi sono $220 al mese su Team e $700 su Business. Il piano Team di Airtable costa $20 per editor al mese e le alternative ad Airtable che evitano questo modello le confrontiamo in una guida a parte. Nulla di tutto ciò è irragionevole per ciò che questi prodotti fanno, ma significa che il costo di uno strumento cresce con la sua adozione, l'opposto di ciò che volete da qualcosa pensato per raggiungere tutta l'azienda.
Cosa ha cambiato l'IA e cosa no
L'IA ha azzerato il costo iniziale di una prima versione. Non ha toccato la coda: qualcuno deve comunque essere responsabile dello strumento, correggerlo quando un processo cambia e rispondere dei dati che contiene. Il sondaggio di Retool è istruttivo su questo punto. Il 51% degli intervistati ha messo in produzione software con l'IA e circa la metà risparmia sei ore o più a settimana. Eppure solo il 31% arriva ad applicazioni complete con i prompt e appena l'8% usa codice generato dall'IA senza modifiche. La generazione è un punto di partenza che le persone rivedono, non un distributore automatico.
Come creare uno strumento interno in sei passaggi
Il metodo è lo stesso qualunque strada abbiate scelto. I primi tre passaggi producono documenti, non software, ed è lì che dovrebbe andare la maggior parte del tempo.
Passaggi da 1 a 3: decidere prima di costruire
- 1. Scegliete un solo processo. Non «le operations», ma «una richiesta di acquisto, dalla creazione al pagamento». Scrivetelo in una pagina: chi lo avvia, cosa succede dopo, cosa può andare storto, quando è concluso. Se non riuscite a scrivere la pagina, nessuno strumento risolverà il problema.
- 2. Disegnate il modello dei dati partendo dalle colonne attuali. Elencate ciò che monitorate (richieste, fornitori, approvazioni) e cosa registrate per ciascuno. Una riga di foglio che ripete il nome del fornitore quaranta volte diventa due tabelle collegate. Da tre a sei tabelle coprono la maggior parte delle prime versioni.
- 3. Scrivete la matrice dei ruoli. Una riga per ruolo, una colonna per tabella: può vedere, può creare, può modificare, può approvare. Dieci minuti su questa griglia evitano la categoria di bug più costosa, quella in cui qualcuno vede ciò che non dovrebbe.
Passaggi da 4 a 6: costruire, sperimentare, passare le consegne
- 4. Costruite la versione più piccola che svolga il compito. Un elenco, una pagina di dettaglio, un modulo, il cambio di stato. Niente report e niente notifiche per ora. Con una piattaforma low-code o un creatore con IA sono poche ore di lavoro, e il brief scritto nei passaggi da 1 a 3 è il prompt.
- 5. Fate un pilota con tre utenti reali per una settimana intera. Dati veri, scadenze vere, il vecchio foglio bloccato in sola lettura. Raccogliete ogni lamentela in un unico elenco. Aspettatevi che il modello dei dati cambi una volta: serve a questo, il pilota.
- 6. Passate le consegne. Nominate un responsabile. Mettete il codice in un repository, se c'è del codice, pianificate i backup del database, annotate come aggiungere un utente. Uno strumento senza responsabile è un foglio di calcolo con una pagina di login.
Quattro verifiche prima che tutto il team ci faccia affidamento
Una demo diventa uno strumento il giorno in cui le persone smettono di tenere una copia di riserva dei propri dati. Quattro verifiche decidono se si merita questa fiducia.
| Verifica | La domanda da porsi | Perché conta |
|---|---|---|
| Permessi nel database | Se chiamo l'API con un account normale, posso leggere righe che la schermata nasconde? | I filtri dell'interfaccia sono solo estetica. Le regole devono stare dove stanno i dati |
| Storico | Posso vedere chi ha modificato questo record e quando? | Le dispute e gli errori si risolvono con lo storico, non con la memoria |
| Integrazioni | Dove sono le chiavi API e cosa succede se l'altro sistema è fermo? | Le chiavi nel codice del browser sono pubbliche e i guasti silenziosi corrompono i dati |
| Proprietà | Se il fornitore sparisce o triplica il prezzo, cosa ci resta? | I dati operativi sono l'ultima cosa che un'azienda può permettersi di affittare |
C'è una quinta verifica, più discreta: avvisate l'IT. Nel sondaggio di Retool, il 60% dei builder aveva creato qualcosa fuori dal controllo dell'IT nell'ultimo anno, soprattutto perché era più veloce. La velocità è un buon motivo. Ma uno strumento che contiene dati di clienti o dipendenti deve comparire nell'elenco di qualcuno, con un responsabile, un backup e una revisione degli accessi, prima di diventare critico e non dopo.
Su Cadrant questo flusso è ciò attorno a cui è costruito il prodotto. Descrivete il processo e la piattaforma genera un'applicazione React collegata a un database PostgreSQL nel vostro progetto Supabase, con tabelle, relazioni e indici ricavati dalla vostra descrizione. L'autenticazione usa Supabase Auth con ruoli personalizzati come admin, editor e lettore. Le policy di Row Level Security di base vengono create a partire dal prompt e la documentazione raccomanda di rivederle in Supabase prima della produzione, cioè la prima verifica qui sopra. Le integrazioni girano lato server in Edge Functions con le chiavi salvate come variabili d'ambiente e il codice si sincronizza con un repository GitHub dal piano Pro, $40 al mese qualunque sia il numero di colleghi che usano lo strumento. I dettagli sono nella pagina del creatore di strumenti interni.
- Uno strumento interno fa rispettare il vostro processo; un foglio di calcolo si limita a conservarlo. Bastano due dei cinque segnali per cambiare.
- Nel 2026 le strade sono quattro: SaaS configurato, piattaforma low-code, sviluppo su misura, creatore di app con IA. Confrontatele sul costo a piena adozione e su ciò che vi resta se andate via.
- Processo, modello dei dati e matrice dei ruoli vengono prima e valgono per qualsiasi strada.
- Prima del lancio, verificate permessi a livello di database, storico, integrazioni e proprietà.