A inizio settembre 2025 ho ricevuto la chiamata di un imprenditore con un’idea precisa: un SaaS B2B per psicoterapeuti italiani, una piattaforma verticale che mettesse in un solo flusso agenda, video call clinica, fatturazione elettronica via SDI, note di seduta cifrate. Niente Calendly bricolato con Stripe e Zoom, niente fogli Excel per il fatturato a fine anno. Uno strumento che parlasse il linguaggio del professionista della salute mentale, non quello del SaaS generalista. Voleva mettere il primo cliente pagante entro fine novembre. Tre mesi netti. Vedi anche gli altri post di questa rubrica: Fieldwork.
Per chiarezza sul perimetro: la piattaforma è strumento per professionisti che esercitano in autonomia. Ogni psicoterapeuta è titolare del trattamento dei dati dei propri pazienti; Romiltec opera come responsabile del trattamento ex art. 28 GDPR per il committente che gestisce la piattaforma.
Il committente non era un developer e non aveva un team tecnico interno. Aveva un dominio chiaro (formazione clinica e rete di colleghi), un capitolato di una pagina, un budget definito, e un calendario non negoziabile: dicembre 2025 con piattaforma in produzione e primo cliente pagante. Per Romiltec è il tipo di richiesta che si firma in due call: scope verticale, deadline esplicita, sponsor che decide.
Le 12 settimane: il metodo, non l’aforisma
Lavoriamo a sprint agili a prezzo fisso mensile. Non è una scelta di marketing, è una scelta operativa: con 5 persone bootstrap e zero commerciali, l’unico modo per non bruciarsi su un nuovo cliente è fissare la cadenza. Tre sprint da 4 settimane, deliverable noti per ogni sprint, demo settimanale in screen share col committente e con i tre psicoterapeuti early adopter che lui aveva pre-arruolato fra colleghi.
Le 12 settimane non sono un trucco da hackathon, sono un vincolo di metodo: se non riesci a portare un MVP in produzione in tre mesi, vuol dire che lo scope non è verticale abbastanza, o che stai costruendo per ipotesi invece che per persone. Nel nostro caso lo scope era già stato tagliato in fase di proposta: niente CRM, niente marketing automation, niente analytics avanzato. Solo il flusso clinico end-to-end.
Il dominio prima del codice
Prima settimana: niente repo, niente Figma, niente design system. Tre call da un’ora con tre psicoterapeuti diversi, in screen share su come oggi gestiscono in pratica i pazienti. Cosa salta fuori se non te lo racconta nessuno:
- Le sedute si spostano. Tantissimo. Una piattaforma che non gestisce la riprogrammazione con un click è morta in due settimane.
- Il professionista raramente fattura paziente per paziente la sera stessa. Lo fa in batch, in fondo al mese, sotto pressione. Una UI di fatturazione che non supporta il batch firmato in massa è inutile.
- Le note cliniche rientrano nelle categorie particolari ex art. 9 GDPR. Il titolare del trattamento (lo psicoterapeuta) deve avere base giuridica solida (di norma: necessità di assistenza sanitaria ex art. 9 par. 2 lett. h) e informativa specifica per ogni paziente. Il software custodisce, non sostituisce questa responsabilità.
- L’informativa e il consenso informato vanno gestiti come asset versionati lato titolare, non come PDF allegato a una mail.
Il capitolato del committente diceva “agenda, video, fattura, note”. Dopo le tre call la lista si è risistemata in: gestione robusta della riprogrammazione, fatturazione batch con FE verso SDI italiano, note cliniche con cifratura end-to-end e log di accesso, video call con stanza dedicata per terapeuta e paziente. Lo stesso scope, ma ordinato per dolore reale.
Stack: scelte pragmatiche, non religiose
Backend Laravel 12 su PHP 8.3, frontend Vue 3 con Vuetify 3, MariaDB 11 come primario, Redis per coda e cache, queue Horizon per i job lunghi (rendering PDF fatture, push verso SDI, notifiche). Su questo stack abbiamo già il muscle memory: è quello del nostro prodotto principale e di metà del portfolio (vedi il pivot da servizi a prodotto). Andare con uno stack che conosci dentro è la cosa che ti compra le settimane sul calendario.
Per i pezzi specifici del verticale clinico:
- Fatturazione elettronica via SDI. Non l’abbiamo riscritta noi. Adapter sopra un provider italiano accreditato che gestisce conservazione sostitutiva e firma, con webhook firmato per gli stati di consegna. Quattro stati canonici (in invio, accettata da SDI, scartata, consegnata) mappati in un’unica state machine sul nostro modello
Invoice. Il giorno del go-live il 100% delle fatture batch generate dalla prima settimana di pilota è passato il check SDI al primo tentativo: piccolo numero su volumi piccoli, ma nessun rework manuale, che è quello che conta per il professionista. - Video call sicura. Niente Jitsi self-hosted al primo giorno (operativamente fragile, scope troppo largo per uno sprint da 4 settimane). Integrazione SDK con un provider WebRTC europeo, stanze monouso generate al momento del check-in, niente recording lato server, link firmato a scadenza breve.
- Note cliniche con cifratura applicativa. Cifratura applicativa lato backend con derivazione chiave per-utente da master tenant-specific custodita in un servizio dedicato (KMS esterno). I dettagli specifici dell’implementazione restano riservati per ragioni difensive. Il database vede solo blob cifrati: anche un dump non autorizzato non espone testi. Log di accesso ad ogni read della nota, conservato secondo i tempi previsti dalla policy del titolare, esportabile per il professionista in caso di richiesta di audit.
- Calendario sync. CalDAV bidirezionale verso Google Calendar e Apple Calendar via iCloud. La maggior parte dei terapeuti vive sull’agenda del telefono, non sul nostro back office: se non gli portiamo lo slot lì, non lo guardano.
- Onboarding e consenso informato versionato. Il consenso non è un checkbox: è un documento PDF firmato graficamente dal paziente al primo accesso, archiviato con hash e timestamp, riemesso quando cambia di versione.
Stripe è dentro per gli abbonamenti del professionista (non per il pagamento delle sedute, che resta extra-piattaforma per scelta del committente). Mailgun per le email transazionali. Sentry per error tracking. Tutto deploy in container Docker, CI/CD su GitHub Actions, deploy su VM dedicate Hetzner con backup ZFS giornaliero off-site.
Il pilota: tre psicoterapeuti dentro al processo
Dalla settimana 4 alla settimana 8 tre psicoterapeuti early adopter hanno fatto onboarding completo: configurazione del proprio profilo, creazione di pazienti di prova (anonimizzati e firmati come “demo”), simulazione di sedute e generazione del materiale fatturabile. Niente dati clinici reali in pilota: per quel passaggio servono DPIA dedicata e base giuridica formalizzata che il committente avrebbe predisposto in fase post-pilota. Non era un focus group, era stress test realistico del flusso. Demo settimanale di un’ora il venerdì pomeriggio, screen share sui loro casi demo, bug log condiviso. Le critiche più dure, quelle che ti fanno cambiare la UI in due giorni, le hanno fatte loro: una nota sul fatto che il pulsante di chiusura cartella era troppo vicino a “elimina seduta”, una riprogrammazione che richiedeva tre click invece di uno, una pagina di fatturazione batch che non mostrava il totale lordo per anno corrente.
Lavorare dentro al processo è il metodo che usiamo da sempre. Per anni ottimizzando un software di magazzino ho passato giorni a chiudere pacchi col reparto: lo stesso approccio applicato a un dominio sanitario significa stare nelle call con i professionisti, leggere il loro modulo di consenso, capire perché un terapeuta fattura sempre di lunedì e mai di venerdì.
I numeri al go-live
Settimana 12, fine novembre 2025: piattaforma in produzione, primo cliente pagante esterno arrivato via passaparola del committente, i tre early adopter trasformati in clienti paganti scontati per i primi 6 mesi. Nelle 4 settimane successive al go-live altri 9 professionisti hanno completato l’onboarding: il committente puntava a 10 nei primi tre mesi, ne abbiamo fatti 13 nel primo mese e mezzo. Numeri piccoli in valore assoluto, ma su un mercato verticale italiano con CAC zero (solo passaparola della rete del committente) sono il segnale operativo che la promessa funziona.
Il dato che a me interessava di più era un altro: percentuale di fatture passate da SDI al primo tentativo, tempo medio fra “fine seduta” e “fattura emessa”, tempo medio di apertura di una nota clinica esistente. I tre early adopter hanno smesso di usare il loro vecchio mix di tool dopo il giorno 10 del pilota. Quella è la metrica che dice se hai costruito uno strumento o un giocattolo.
Cosa porto via dalle 12 settimane
Tre cose, in ordine.
Una. Il verticale paga la verticalità. Su un dominio dove il professionista è abituato a tenere insieme cinque tool generalisti, l’arrivo di uno strumento che parla esattamente la sua lingua produce conversione veloce. Non per la UX più bella, ma perché ogni feature è in posto giusto.
Due. Le 12 settimane funzionano se hai un committente che decide. Se sopra di te c’è un comitato che approva ogni screen, il calendario salta al primo sprint. La proposta commerciale per questo tipo di lavori la facciamo solo quando c’è un singolo sponsor con autorità di firma e di scope.
Tre. Non si parte dal codice. Si parte dalle call con tre persone che fanno il mestiere, in screen share, senza Figma sotto. Il design system arriva alla settimana 3, non alla settimana 1. Il rischio peggiore in un MVP verticale è costruire bene la cosa sbagliata: lo eviti solo stando nel processo prima di scrivere la prima migration.
A dicembre 2025 questa piattaforma è in produzione, fattura, ha utenti che la usano ogni giorno per pazienti veri. Per noi è stato uno sprint denso ma metodologicamente ordinario: lo stesso schema dei progetti custom che firmiamo da Romiltec ogni mese, applicato a un dominio dove la verticalità conta più della scala. Il committente non si aspettava di essere in produzione il primo dicembre. Ci siamo riusciti perché lo scope l’avevamo tagliato bene insieme a settembre, non perché abbiamo lavorato di più.