Sviluppo custom vs SaaS per dati catastali: come decidere (guida 2026)
Chi deve integrare dati catastali in un prodotto - una piattaforma PropTech, uno strumento di due diligence immobiliare, un sistema interno per uno studio notarile o un fondo - arriva quasi sempre alla stessa domanda: conviene appoggiarsi a un servizio già pronto (un'API, un SaaS) o commissionare uno sviluppo su misura?
Non è una domanda ideologica. È una domanda di allocazione del budget che va affrontata con un framework, non con un'intuizione. Questo articolo prova a darne uno, basato su cosa cambia davvero tra i due percorsi quando si parla specificamente di dati catastali italiani - un dominio con caratteristiche proprie (fonte pubblica ma senza API ufficiale, formati eterogenei, normative che cambiano) che rendono la scelta diversa rispetto a un generico "build vs buy" da manuale di startup.
tl;dr
- Una SaaS/API già pronta (come visura-api o le nostre API dati catastali) basta quando il volume è medio-basso, il caso d'uso è standard, e non serve incrociare i dati catastali con logiche di business proprietarie.
- Serve sviluppo custom quando i dati catastali sono solo un ingrediente di un prodotto più ampio, quando servono SLA e disponibilità garantiti, o quando il volume/la scala rendono insostenibile un costo per-chiamata.
- Nella maggior parte dei progetti reali che seguiamo, la risposta corretta è ibrida: partire da infrastruttura dati già pronta e costruire sopra solo il livello che è davvero specifico del business.
Il costo nascosto che nessuno dei due lati racconta per intero
Chi vende soluzioni SaaS tende a minimizzare i costi di integrazione a lungo termine (rate limit, vendor lock-in, personalizzazione limitata). Chi vende sviluppo su misura tende a minimizzare i tempi e i rischi di un progetto costruito da zero (manutenzione, bug in produzione, il primo anno in cui il team interno impara a conoscere un dominio - il catasto italiano - che ha le sue insidie).
La verità utile è più noiosa: entrambi i percorsi hanno un costo totale di proprietà (TCO) che si vede solo a 18-24 mesi, non al preventivo iniziale. Un SaaS con pricing per chiamata può sembrare economico a 500 richieste al mese e diventare insostenibile a 50.000. Uno sviluppo custom può sembrare più costoso all'inizio e ripagarsi in 14 mesi se il prodotto ha una vita di 5 anni.
Quando una soluzione già pronta basta (ed è la scelta giusta)
Ci sono situazioni in cui commissionare sviluppo su misura per l'accesso a dati catastali è, onestamente, uno spreco.
Il caso d'uso è di consultazione, non di prodotto. Se il bisogno è "recuperare N visure al mese per il mio studio" o "verificare la categoria catastale di un immobile prima di un'offerta", un servizio come visura-api - progetto open source AGPL-3.0 che automatizza il portale SISTER dell'Agenzia delle Entrate - risolve il problema in ore, non in mesi. Non ha senso pagare un team di sviluppo per ricostruire quello che esiste già e funziona.
Il volume è medio-basso e prevedibile. Sotto qualche migliaio di chiamate al mese, il costo per-richiesta di un'API pronta è quasi sempre inferiore al costo di mantenere in vita un sistema proprietario (server, patching, monitoraggio, la persona che sa come funziona quando va in ferie).
Il dato serve così com'è, senza incroci proprietari. Se basta la rendita catastale, la categoria, l'indirizzo - senza doverli mettere in relazione con altri dataset di business interni (portafoglio clienti, storico transazioni, scoring proprietario) - un'API generica copre il 100% del bisogno.
Il time-to-market conta più della personalizzazione. Un MVP che deve validare un'ipotesi di business in 6 settimane non ha lo spazio per commissionare un backend da zero. Si integra un'API pronta, si valida l'ipotesi, e poi si decide se vale la pena internalizzare.
Quando serve sviluppo custom
All'estremo opposto, ci sono contesti in cui una SaaS generica - per quanto ben fatta - smette semplicemente di essere adatta.
I dati catastali sono un ingrediente, non il prodotto. Una piattaforma PropTech che deve incrociare catasto, quotazioni OMI, rischio idrogeologico, demografia e dati proprietari (es. storico prezzi di un fondo, portafoglio di un gestore) in un'unica vista coerente non trova questo incrocio in nessun servizio pronto all'uso, perché è specifico del business del cliente. Qui il valore non è "accedere al dato catastale", è "costruire l'unica vista che la tua azienda ha su quei dati".
Servono SLA e disponibilità garantiti. Un prodotto mission-critical (un sistema di allerta, un tool usato in tempo reale da un team commerciale, un backend che alimenta decisioni di investimento) non può dipendere da un servizio terzo il cui uptime non è contrattualizzato con te. Serve un'architettura pensata per il tuo carico, con SLA che qualcuno può firmare.
Il volume rende insostenibile un costo per-chiamata. Oltre una certa scala (decine di migliaia di richieste al mese, o un'elaborazione batch su milioni di record), il pricing a consumo di un SaaS generico diventa più costoso di un'infrastruttura dedicata, anche includendo i costi di sviluppo e manutenzione.
Serve integrazione profonda in un prodotto proprietario. Se il dato catastale deve entrare in un flusso applicativo con autenticazione, permessi, audit trail, notifiche - tutto ciò che rende un'API generica non sufficiente - il livello di integrazione richiesto è di fatto sviluppo software, non semplice consumo di endpoint.
Un framework in 5 domande
Prima di aprire una gara o scrivere un capitolato, vale la pena rispondere onestamente a queste cinque domande.
- Il dato catastale è il prodotto finale, o un ingrediente di qualcos'altro? Se è il prodotto finale (es. "vendo report catastali"), quasi certamente basta un'API pronta con un layer di presentazione sopra. Se è un ingrediente incrociato con logiche proprietarie, serve sviluppo custom almeno per il livello di aggregazione.
- Quante richieste/elaborazioni al mese, oggi e tra 18 mesi? Fai il conto con numeri reali, non stime ottimistiche. La curva di crescita cambia radicalmente quale opzione conviene.
- Serve un SLA contrattuale sull'uptime? Se la risposta è sì e riguarda un processo di business critico, uno strato di infrastruttura dedicata (anche se costruita sopra un'API terza) è quasi sempre necessaria.
- Il dato deve integrarsi con sistemi interni (CRM, ERP, data warehouse proprietario)? Ogni punto di integrazione aggiuntivo è un argomento a favore di uno sviluppo su misura, perché un'API generica non conosce lo schema dei tuoi sistemi interni.
- Quanto vale, in termini di time-to-market, partire subito con un'integrazione pronta rispetto ad aspettare 3-4 mesi di sviluppo? Se stai validando un'ipotesi di business, il tempo spesso vale più della personalizzazione. Se hai già validato e stai scalando, vale il contrario.
Il modello ibrido: quasi sempre la risposta reale
Nella nostra esperienza, la maggior parte dei progetti seri non è né "tutto SaaS" né "tutto costruito da zero". È un ibrido: si parte dall'infrastruttura dati già pronta e disponibile - le nostre API dati catastali, visura-api per l'accesso a SISTER, i dataset gratuiti per l'analisi territoriale - e si costruisce su misura solo il livello che è genuinamente specifico del business: l'aggregazione, l'autenticazione, la logica di dominio, l'interfaccia utente, le notifiche.
Questo approccio riduce il rischio di progetto (non si riparte da zero sull'ingestione dati, un lavoro che richiede mesi e competenza specifica sul dominio catastale italiano) e concentra il budget di sviluppo su ciò che crea davvero un vantaggio competitivo: la parte che nessun fornitore generico può replicare perché è specifica della tua azienda.
È il modello che seguiamo quando lavoriamo su piattaforme di integrazione dati catastali: partiamo da un'infrastruttura dati già arricchita (85 milioni di particelle catastali, quotazioni OMI, mappe di rischio territoriale) invece che dalla raccolta dati da zero, e il progetto si concentra sull'integrazione nel tuo prodotto - autenticazione, sessione, logica di business, interfaccia.
Cosa cambia nei costi, in pratica
Per dare un ordine di grandezza realistico, senza promettere cifre valide per ogni caso:
- Un modulo singolo di integrazione (es. automazione visure per un caso d'uso circoscritto) parte in genere da qualche migliaio di euro.
- Una pipeline completa con normalizzazione, monitoring, arricchimento multi-fonte e integrazione in un prodotto esistente richiede tipicamente un budget a 5 cifre.
- Per prodotti mission-critical con SLA, alta disponibilità e manutenzione continuativa, il modello spesso più sensato è una partnership con canone ricorrente invece che un progetto una tantum - perché il lavoro di manutenzione (SISTER cambia interfaccia, l'Agenzia delle Entrate aggiorna formati, le normative si evolvono) non si esaurisce al collaudo.
Come lo affrontiamo noi
Quando lavoriamo su integrazioni dati catastali su misura, la prima conversazione con un cliente è quasi sempre esattamente questo esercizio: capire se il bisogno è di consultazione (e allora orientiamo verso visura-api o le API dati catastali) o se è di prodotto (e allora ha senso investire in sviluppo su misura sopra un'infrastruttura dati già pronta, invece che ricostruire l'ingestione da zero). Non è un esercizio di vendita: è spesso la conversazione che fa risparmiare al cliente un progetto sovradimensionato.
Domande frequenti
Conviene sempre partire da un'API pronta invece che da uno sviluppo custom?
Nella maggior parte dei casi sì, almeno per la parte di accesso al dato grezzo: riduce tempo e rischio di progetto. Lo sviluppo custom ha senso per il livello di aggregazione e logica di business che è specifico della tua azienda.
Quando un SaaS con pricing per chiamata diventa più costoso di un'infrastruttura dedicata?
Dipende dal pricing specifico, ma indicativamente sopra qualche decina di migliaia di richieste al mese conviene iniziare a valutare un'architettura dedicata, soprattutto se il volume continua a crescere nel tempo.
Posso passare da SaaS a sviluppo custom in un secondo momento senza ripartire da zero?
Sì, è il pattern più comune: si valida il prodotto con un'integrazione rapida, e solo dopo aver validato il modello di business si investe in un'infrastruttura dedicata, spesso riusando la stessa logica applicativa già scritta sopra l'API.
visura-api può essere usato dentro un prodotto commerciale proprietario?
Sì, ma va tenuto conto della licenza AGPL-3.0: se usato/modificato ed esposto via rete in un servizio proprietario, richiede la pubblicazione del codice sorgente combinato, salvo acquisto della licenza commerciale separata pensata proprio per questo caso.
Quanto costa indicativamente passare dal proof of concept a un sistema in produzione?
Un modulo singolo parte da qualche migliaio di euro; una pipeline completa con normalizzazione, monitoring e integrazione in un prodotto esistente richiede tipicamente un budget a 5 cifre, spesso strutturato come partnership continuativa per la manutenzione.
Chi dovrebbe valutare se conviene build o buy, in azienda?
Idealmente una decisione congiunta tra chi guida il prodotto (che conosce il time-to-market necessario) e chi guida la tecnologia (che conosce il TCO reale a 18-24 mesi), non solo il team di procurement sul preventivo iniziale.
Zornade offre entrambi i percorsi?
Sì: API e dataset già pronti per chi ha bisogno di consultazione o volumi medio-bassi, e sviluppo su misura per chi deve integrare dati catastali in un prodotto proprietario con logiche di business specifiche.