Checklist prima di commissionare una piattaforma PropTech (2026)

Il mercato PropTech italiano è affollato di promesse e povero di framework di valutazione. Chi deve commissionare - da zero o come evoluzione di un prodotto esistente - una piattaforma PropTech si trova davanti a un ventaglio di opzioni molto ampio: boutique specializzate nel settore, software house generaliste che aggiungono "PropTech" al proprio elenco servizi, freelance, team interni da assumere. Distinguerle richiede fare le domande giuste, prima di firmare, non dopo il primo rilascio in ritardo.

Questa checklist nasce dall'esperienza diretta di chi ha costruito il livello di aggregazione dati per piattaforme PropTech reali - incrociando catasto, quotazioni OMI e informazioni di mercato in un profilo unico per immobile. Non è una lista teorica: sono le domande che avremmo voluto sentirci fare, e quelle che avremmo voluto fare noi stessi, nei progetti che sono partiti male.

tl;dr

• La domanda più trascurata è quella sui dati: da dove vengono, chi li possiede legalmente, quanto costa aggiornarli nel tempo.
• Il team conta più dello stack tecnologico: cercare esperienza reale nel dominio immobiliare/catastale, non solo competenza generica di sviluppo.
• Il contratto deve chiarire proprietà del codice, exit clause e costo della manutenzione post-lancio - non solo il prezzo dello sviluppo iniziale.

1. I dati: la domanda che va fatta per prima

Una piattaforma PropTech vale quanto i dati che la alimentano. Prima di parlare di funzionalità, chiedi al fornitore:

• Da dove arrivano i dati (catasto, OMI, rischio territoriale, demografia, dati proprietari)? Sono fonti pubbliche verificabili o stime proprietarie del fornitore?
• Con quale frequenza si aggiornano, e chi si assume la responsabilità dell'aggiornamento nel tempo? Un dataset "scaricato una volta" invecchia in mesi.
• Qual è la licenza d'uso dei dati sottostanti? I dati pubblici italiani (Agenzia delle Entrate, ISPRA, ISTAT) hanno condizioni di riuso specifiche che vanno rispettate, soprattutto se il tuo prodotto li ridistribuisce a clienti terzi.
• Il fornitore ha già un'infrastruttura dati pronta, o il progetto prevede di costruirla da zero come parte del budget? Sono due preventivi molto diversi, spesso presentati come se fossero comparabili.

Un fornitore che risponde con precisione a queste domande - fonti nominate, non genericamente "dati di mercato" - è un segnale di affidabilità concreto.

2. Architettura: cosa chiedere oltre allo stack tecnologico

Il nome dello stack tecnologico (React, Node, PostgreSQL, e così via) conta meno di come è pensata l'architettura per il tuo caso specifico.

• La piattaforma è pensata per scalare oltre il primo cliente/mercato, o è un prototipo che regge solo la demo?
• I dati sono aggiornabili senza downtime, o ogni refresh richiede un intervento manuale?
• Esiste un livello di API che permette, in futuro, di integrare la piattaforma con altri sistemi (CRM, gestionali, data warehouse) senza doverla riscrivere?
• Come viene gestita la crescita del volume dati (nuovi immobili, nuove zone geografiche, nuove fonti)? Un'architettura pensata per 10.000 immobili non regge automaticamente a 1 milione.

3. Il team: l'esperienza di dominio conta più del portfolio generico

Il settore immobiliare/catastale italiano ha specificità normative e di dato che un team senza esperienza diretta impara sulla pelle del tuo progetto - a tue spese, in termini di tempo.

Domande utili:

• Il team ha già lavorato con dati catastali italiani reali (non solo dati immobiliari generici o internazionali)?
• Può mostrare case study verificabili, con dettagli tecnici concreti, non solo loghi cliente su una slide?
• Chi, nel team, ha competenza specifica su normativa catastale/OMI, e chi è puro sviluppo software? Un progetto PropTech serio ha bisogno di entrambe le competenze, non solo della seconda.

4. Sicurezza e compliance

Una piattaforma che tratta dati immobiliari - spesso collegati a informazioni personali dei proprietari - ha obblighi di compliance che vanno chiariti prima, non scoperti durante un audit.

• Come vengono gestiti i dati personali eventualmente collegati agli immobili (proprietari, contatti), rispetto al GDPR?
• Dove sono ospitati i dati (data residency), e con quali garanzie di backup e disaster recovery?
• Esiste un piano per gli accessi e permessi (chi nel tuo team vede cosa), o tutto è amministrato con un unico account condiviso?

5. Il contratto: le clausole che contano più del prezzo

Il prezzo dello sviluppo iniziale è la parte più visibile del contratto, ma non è quella che determina se il progetto sarà un successo o un problema tra 12 mesi.

• Chi possiede il codice sorgente al termine del progetto? Se il fornitore mantiene la proprietà, cosa succede se decidi di cambiare fornitore?
• Cosa succede se vuoi cambiare fornitore (exit clause)? È prevista una fase di trasferimento della conoscenza (knowledge transfer), o resti bloccato con l'unico team che capisce il sistema?
• Quanto costa la manutenzione post-lancio, ed è inclusa nel contratto iniziale o negoziata separatamente dopo? Le fonti dati catastali/OMI cambiano nel tempo (formati, normative): un sistema "consegnato e abbandonato" invecchia rapidamente.
• È previsto un canone continuativo o solo un progetto una tantum? Per piattaforme che devono restare aggiornate nel tempo, un modello di partnership continuativa è spesso più realistico di un progetto chiuso.

6. Red flag comuni nel settore

Alcuni segnali che, nella nostra esperienza, meritano più domande prima di procedere:

• Promesse di dati "esclusivi" senza fonte nominabile. Se un fornitore non riesce a dire da dove viene un dato, è un problema che si eredita.
• Preventivi che non distinguono sviluppo iniziale da manutenzione. Se il costo della manutenzione non è discusso finché non è troppo tardi, è un segnale di scarsa trasparenza.
• Case study senza dettagli tecnici verificabili. "Abbiamo lavorato con aziende leader del settore" senza nomi, numeri o link è un'affermazione che non si può verificare.
• Nessuna menzione della scalabilità dei dati oltre il primo mercato/cliente. Chi non ha pensato a cosa succede al decimo cliente probabilmente costruirà un sistema che va rifatto al decimo cliente.

Cosa fa la differenza tra un prototipo e una piattaforma che decolla

Nella nostra esperienza diretta, il fattore che separa i progetti PropTech che restano un demo da quelli che diventano un prodotto reale non è quasi mai la qualità del frontend. È la solidità del livello di aggregazione dati - la capacità di prendere fonti eterogenee (catasto, OMI, rischio territoriale, dati proprietari) e trasformarle in un profilo coerente per ogni immobile, aggiornato nel tempo, senza intervento manuale continuo. È un lavoro meno visibile di una bella dashboard, ma è quello che determina se la piattaforma regge alla scala e al tempo.

Quando lavoriamo su progetti PropTech su misura, partiamo esattamente da questo livello: un'infrastruttura dati già arricchita (85 milioni di particelle catastali, quotazioni OMI, mappe di rischio territoriale già incrociabili) invece che dalla raccolta dati da zero - così il budget si concentra sull'integrazione nel tuo prodotto, non sulla reinvenzione dell'ingestione dati.

Domande frequenti

Quanto tempo richiede tipicamente lo sviluppo di una piattaforma PropTech su misura?

Dipende dallo scope: un modulo di aggregazione dati per un caso d'uso circoscritto può richiedere alcune settimane; una piattaforma completa con dashboard, autenticazione e integrazioni multiple richiede tipicamente alcuni mesi.

Devo avere già i dati o posso partire da zero?

Entrambe le opzioni sono percorribili. Se hai già un dataset immobiliare, l'integrazione si costruisce sopra quello; se parti da zero, si può attingere a infrastrutture dati già pronte (particelle catastali, quotazioni OMI, fonti pubbliche già integrate) invece di raccogliere tutto da zero.

Come faccio a verificare che i case study di un fornitore siano reali?

Chiedi dettagli tecnici specifici (non solo il nome del cliente), link verificabili quando disponibili, e la possibilità di parlare direttamente con un referente tecnico del progetto citato, se il fornitore lo consente.

Cosa succede se il fornitore chiude o smette di operare?

È esattamente la domanda a cui deve rispondere la exit clause nel contratto: proprietà del codice, documentazione tecnica consegnata, possibilità di knowledge transfer verso un altro team. Va negoziata prima della firma, non dopo un problema.

Conviene un fornitore generalista o uno specializzato in PropTech?

Dipende dal progetto: se il valore del prodotto sta nell'aggregazione di dati immobiliari/catastali complessi, l'esperienza di dominio specifica riduce il rischio. Se il PropTech è solo il settore di applicazione di un problema software generico (es. un gestionale interno), la specializzazione conta meno.

Quanto costa indicativamente un progetto PropTech su misura?

Varia molto in base a scope e integrazioni richieste: un modulo di aggregazione dati parte da qualche migliaio di euro, una piattaforma completa con dashboard e automazione richiede in genere un budget a 5 cifre.

Perché la manutenzione post-lancio è così importante per una piattaforma PropTech?

Perché le fonti dati sottostanti (catasto, OMI, normative) cambiano nel tempo. Una piattaforma "consegnata e abbandonata" mostra dati sempre più vecchi e perde valore rapidamente, indipendentemente da quanto fosse ben costruita al lancio.