Costruire PropTech come Operatore di Asset

Gestisco tre affitti a breve termine tra l'Algarve e l'Andalusia. La piattaforma che li gestisce è React + Supabase + Lovable Cloud. Mi chiedono se lo stack scala. Sì — ma non nel modo in cui lo immaginano i blog.

Ho iniziato leggendo consigli PropTech. Il consiglio era uniforme: costruire per gli inquilini, progettare per la scala, astrarre il modello di proprietà perché funzioni su diverse classi di asset. Abbastanza generico da poter essere concesso in licenza ad altri operatori in futuro.

Quel consiglio è corretto — per un tipo di PropTech.

Ne esistono due tipi, e dall'esterno sembrano uguali.

Il primo tipo vende governance ad altri operatori. Il prodotto è l'astrazione: un modello multi-tenant che funziona su diverse classi di asset, configurabile per cliente, disaccoppiato dall'operazione reale di chi lo acquista. Scala orizzontale: più clienti, ciascuno con la propria operazione sopra la piattaforma.

Il secondo tipo gestisce gli asset propri dell'operatore. Il prodotto è l'integrazione: un accoppiamento profondo con il modo in cui faccio l'onboarding degli ospiti, definisco i prezzi delle proprietà, sincronizzo i calendari, gestisco la compliance. Scala verticale: più asset miei, più giurisdizioni, più proprietari sotto la mia gestione — ma la piattaforma è mia, non concessa in licenza.

Entrambi scalano. Entrambi sono business reali. Scalano semplicemente su assi diversi.

Sto costruendo il secondo tipo. Ecco cosa significa in pratica.

La piattaforma è multi-tenant — per i miei proprietari, non per altri operatori. Row-Level Security e MFA esistono perché gestisco asset per conto di proprietari che hanno bisogno di un accesso limitato alle proprie finanze. Aggiungere il decimo proprietario è una modifica di configurazione, non una riscrittura dell'architettura. Ma qui "tenant" significa "proprietario con cui lavoro", non "cliente PropTech che mi paga una fee SaaS".

La compliance è codificata per le giurisdizioni in cui opero. RNAL in Portogallo. NRUA in Spagna. GDPR ovunque. La piattaforma codifica questi elementi come predefiniti perché so in quale giurisdizione si trova ogni proprietà. Aggiungere una terza giurisdizione (EAU, Francia) è un fork delle impostazioni predefinite di compliance — stessa architettura, più regole. La piattaforma supporta l'orizzontalità per giurisdizione anche quando non supporta l'orizzontalità per cliente.

Le edge functions automatizzano le mie operazioni ricorrenti. Cinque edge functions in produzione gestiscono attività che altrimenti consumerebbero il mio tempo: sincronizzazione iCal da Airbnb (sync-ical-feeds), ciclo di vita dei token del portale proprietari (generate / validate / revoke tokens) e instradamento delle email di contatto. Ognuna sostituisce un'attività manuale ricorrente per proprietà. Aggiungere la quarta proprietà non aggiunge quattro ore di amministrazione settimanale — le edge functions le assorbono. Questa è scala verticale.

Il vincolo non è la capacità, è il posizionamento. Potrei concedere questo in licenza a un altro operatore domani? Tecnicamente sì — Supabase è multi-tenant, il codice è abbastanza pulito. Ma il giorno in cui volessi vendere questo come SaaS, l'architettura cambierebbe: configurabilità al posto di predefiniti, workflow astratti al posto di compliance codificata in modo fisso, un livello di customer success, fatturazione. È un prodotto diverso, non un refactor. Ed è una scelta strategica non costruirlo.

La trappola della PropTech da operatore non è fingere che sia un futuro SaaS. È fingere che la scelta non esista. C'è un bivio reale: vendi governance ad altri operatori, oppure operi? Vendere significa investire in astrazione, configurabilità, onboarding dei clienti, supporto. Operare significa investire in un'integrazione profonda con le proprie operazioni, compliance per le proprie giurisdizioni, automazione delle proprie attività ricorrenti.

Entrambi portano da qualche parte. Portano in posti diversi.

Per ora, sto operando. La piattaforma scala con me — più proprietà, più proprietari, più giurisdizioni, automatizzata dove conta. Il giorno in cui la domanda strategica sarà "LusiberiaStays dovrebbe diventare una PropTech SaaS?" sarà il giorno in cui inizierà la conversazione sull'architettura. Oggi non è quel giorno.

La PropTech che gestisco gestisce me. Non è un limite. È il design.

Fonti

• LusiberiaStays operations stack: React 18 + TypeScript + Supabase + Lovable Cloud
• Compliance frameworks: PT DL 128/2014 (consolidated DL 76/2024), ES Decreto 28/2016, GDPR
• Edge functions in production: sync-ical-feeds, send-contact-email, generate-portal-token, validate-portal-access, revoke-portal-token
• Properties under management: 3 (Algarve, Algarve, Andalucía)
• Multi-tenant architecture: Row-Level Security on Supabase, MFA TOTP on admin, owner portal with token-scoped access