Due aziende su tre che adottano piattaforme low-code in ambito enterprise finiscono per richiedere interventi custom entro 18 mesi. Non perché il low-code sia sbagliato, ma perché viene usato dove non dovrebbe. Ecco come scegliere senza pentimenti.
Panoramica in 20 secondi
Iniziamo da una storia che abbiamo visto ripetersi decine di volte. Un responsabile IT di un'azienda manifatturiera lombarda con circa 200 dipendenti decide di usare Power Apps per digitalizzare le richieste di ferie, le note spese e un paio di checklist di magazzino. In tre settimane il sistema è in produzione, i costi sono contenuti nella licenza Microsoft 365 già attiva, e il direttore generale è entusiasta. Fin qui il low-code fa esattamente quello per cui è nato: applicazioni interne a bassa complessità, dove la logica di business è lineare e il numero di utenti concorrenti è limitato. Lo stesso vale per dashboard dipartimentali costruite con Retool, prototipi rapidi su Bubble per validare un'idea di prodotto, o automazioni su Mendix che collegano un CRM a un foglio di calcolo. Sono scenari in cui la piattaforma copre l'80-90% dei requisiti con componenti nativi, il tempo di sviluppo si misura in giorni, e la manutenzione è quasi nulla. In questi casi, chi sceglie lo sviluppo custom sta sprecando budget — è un dato di fatto.
Il problema emerge quando quell'entusiasmo iniziale spinge l'azienda a caricare sulla piattaforma low-code qualcosa di più ambizioso. Torniamo alla nostra azienda manifatturiera: dopo il successo delle note spese, il CTO propone di costruire su OutSystems il nuovo sistema di gestione ordini, con logiche di pricing dinamico, integrazione bidirezionale con il gestionale Zucchetti e un motore di regole per gli sconti a cascata per canale di vendita. Sulla carta OutSystems supporta tutto questo. Nella pratica, quando i requisiti superano circa il 70% delle capacità native della piattaforma — una soglia che chi lavora sul campo conosce bene — ogni funzionalità aggiuntiva richiede workaround, codice custom iniettato nei punti di estensione, e un tempo di sviluppo che si avvicina pericolosamente a quello di un progetto tradizionale. Un report Gartner del 2025 conferma questa dinamica: il 65% dei progetti low-code enterprise richiede intervento di sviluppo custom entro 18 mesi dal lancio. Non il 65% dei progetti falliti — il 65% di tutti i progetti enterprise.
C'è poi un aspetto che molti sottovalutano fino a quando non è troppo tardi: il vendor lock-in, ovvero la dipendenza strutturale dalla piattaforma scelta. Con OutSystems o Mendix, la logica applicativa viene espressa in un linguaggio visuale proprietario che non può essere esportato come codice sorgente standard. I dati risiedono in database gestiti dalla piattaforma con schemi non sempre trasparenti. Il pricing scala con il numero di utenti — OutSystems nel 2026 parte da circa 1.513 euro al mese per il piano standard, ma i costi enterprise con utenti illimitati superano facilmente i 100.000 euro annui. Se tra tre anni l'azienda vuole migrare, si ritrova a riscrivere tutto da zero. A livello tecnico, i limiti diventano evidenti sotto carico: impossibilità di ottimizzare singole query SQL, testing automatizzato limitato ai flussi previsti dalla piattaforma, e integrazione con sistemi legacy — pensiamo a un AS/400 ancora in produzione — che richiede middleware custom vanificando il risparmio iniziale. Il low-code non è il problema. Usarlo dove non serve è il problema.
La domanda giusta non è mai 'low-code o custom?' ma 'quale processo sto digitalizzando e quanto è critico per il mio vantaggio competitivo?'. Esiste una regola che in anni di consulenza si è dimostrata sorprendentemente affidabile: se il processo che stai costruendo è una commodity — qualcosa che tutte le aziende del tuo settore fanno nello stesso modo — il low-code è la scelta giusta. Richieste ferie, prenotazione sale riunioni, raccolta feedback interni, approvazioni spese sotto soglia. Sono processi standard dove la velocità di consegna conta più della personalizzazione. Se invece il processo è il tuo vantaggio competitivo — il modo in cui gestisci gli ordini, il tuo algoritmo di pricing, la logica con cui assegni le risorse ai progetti — allora quel codice deve essere tuo, leggibile, testabile, ottimizzabile e indipendente da qualsiasi fornitore di piattaforma. La nostra azienda manifatturiera ha applicato esattamente questo principio: Power Apps per le ferie e le note spese, un sistema custom in TypeScript e PostgreSQL per la gestione ordini che genera il 40% del fatturato.
Guardiamo i numeri concreti, perché è qui che molte decisioni sbagliate nascono da confronti incompleti. Una licenza OutSystems enterprise per un'azienda con 300 utenti costa tra 80.000 e 130.000 euro all'anno, a seconda delle funzionalità e del supporto. In cinque anni sono 400.000-650.000 euro, a cui si aggiungono i costi di sviluppo sulla piattaforma — perché anche il low-code richiede sviluppatori certificati, e uno sviluppatore OutSystems senior costa quanto uno sviluppatore full-stack tradizionale. Un progetto custom equivalente per complessità — poniamo un sistema di gestione ordini con integrazione ERP — richiede un investimento iniziale tra 80.000 e 180.000 euro, con costi di manutenzione annui intorno al 15-20% del valore iniziale. Su cinque anni, il totale custom si attesta tra 140.000 e 320.000 euro. Il custom costa meno nel lungo periodo, e l'azienda possiede il codice sorgente. La differenza è nel flusso di cassa: il low-code distribuisce la spesa, il custom la concentra all'inizio. Ma il costo totale di possesso — il TCO, la metrica che i CFO dovrebbero sempre pretendere prima di firmare — racconta una storia diversa da quella che i commerciali delle piattaforme presentano.
Il modello ibrido funziona quando c'è chiarezza strategica. In pratica significa mappare ogni processo aziendale su una matrice con due assi: complessità tecnica e rilevanza competitiva. I processi a bassa complessità e bassa rilevanza vanno su piattaforme low-code o addirittura su strumenti SaaS già pronti — un Jira per il project management, un HubSpot per il marketing automation. I processi ad alta complessità e alta rilevanza competitiva vanno sviluppati custom, con architetture moderne, test automatizzati, e piena proprietà del codice. Poi c'è la zona grigia — complessità media, rilevanza media — dove la scelta dipende dal contesto specifico: budget disponibile, competenze interne, roadmap di evoluzione prevista. È in questa zona grigia che avere un partner tecnico capace di analisi indipendente fa la differenza tra un investimento azzeccato e un debito tecnico che si accumula silenziosamente. Un'azienda che nel 2026 non ha ancora una strategia chiara su cosa costruire, cosa comprare e cosa delegare a piattaforme low-code sta navigando a vista in un mercato che premia chi è veloce e punisce chi è rigido.
Ogni processo aziendale viene classificato per complessità tecnica e rilevanza competitiva. Questa matrice guida la scelta: SaaS per le commodity, low-code per le utility interne, sviluppo custom per il core business. Nessuna decisione a intuito, solo criteri oggettivi.
Le licenze annuali delle piattaforme low-code nascondono costi che esplodono con la crescita. Confrontiamo TCO reale — licenze, sviluppatori certificati, costi di migrazione — con l'investimento custom ammortizzato, così il CFO firma con dati concreti sul tavolo.
Italy Soft aiuta le aziende a valutare il grado di dipendenza dalla piattaforma attuale e a progettare un percorso di migrazione graduale. Logica di business, dati e integrazioni vengono analizzati per stimare costi e tempi di un eventuale passaggio a soluzioni custom o alternative.
Il modello ibrido funziona solo se i confini tra low-code e custom sono definiti con precisione. API ben documentate separano i due mondi: il low-code gestisce i flussi semplici, il custom gestisce la logica critica, e nessuno dei due invade il territorio dell'altro.
Italy Soft
In 30 minuti di audit gratuito analizziamo i tuoi processi e calcoliamo il ROI concreto. Nessun impegno.