Il dato viene da un sondaggio reale. Non una previsione pessimistica né un racconto ammonitore di un VC, ma una fotografia del mercato della sanità digitale: quasi metà delle startup healthtech aveva meno di dodici mesi di runway. Un altro 12% meno di tre.
La maggior parte dei founder che legge questa statistica pensa che si tratti di finanziamenti. Mercato sbagliato, tempismo sbagliato, investitori che si ritirano.
In parte è così. Ma una quota significativa delle startup healthtech che non ce la fanno non viene uccisa dal mercato. Viene uccisa da decisioni prese nei primi sei mesi di sviluppo: decisioni che al momento sembravano giuste e che poi si sono rivelate fatali.
La scomoda ragione è questa: la maggior parte dei founder healthtech sceglie il partner di sviluppo come lo sceglierebbe per un normale prodotto SaaS. E la sanità non è un normale prodotto SaaS.
La maggior parte dei founder che legge questa statistica pensa che si tratti di finanziamenti. Mercato sbagliato, tempismo sbagliato, investitori che si ritirano.
In parte è così. Ma una quota significativa delle startup healthtech che non ce la fanno non viene uccisa dal mercato. Viene uccisa da decisioni prese nei primi sei mesi di sviluppo: decisioni che al momento sembravano giuste e che poi si sono rivelate fatali.
La scomoda ragione è questa: la maggior parte dei founder healthtech sceglie il partner di sviluppo come lo sceglierebbe per un normale prodotto SaaS. E la sanità non è un normale prodotto SaaS.
Perché la sanità è strutturalmente diversa, e perché molti partner di sviluppo non lo sanno
Ogni prodotto software ha requisiti tecnici. Il software sanitario ha anche un secondo livello: non negoziabile, non rinviabile e non recuperabile se lo si sbaglia.
Il GDPR in Europa. L’HIPAA negli Stati Uniti. L’MDR per tutto ciò che riguarda la classificazione come dispositivo medico. Requisiti di residenza dei dati che variano da Paese a Paese. Flussi di consenso che non sono semplici scelte di UX ma architettura legale. Audit trail che non sono una richiesta di funzionalità ma un obbligo normativo.
Un’agenzia di sviluppo generalista può realizzare un prodotto funzionante. Ciò che di solito non sa fare è prendere fin dal primo giorno le scelte di architettura giuste per restare conformi mentre si cresce, integrarsi senza problemi con i sistemi EHR a cui dovrete collegarvi al diciottesimo mese e produrre la documentazione richiesta da una verifica normativa che non sapevate sarebbe arrivata.
Il problema non è che le agenzie generaliste siano scarse. Il problema è che non sanno cosa non sanno della sanità, e nemmeno la maggior parte dei founder healthtech alla prima esperienza. Così nessuno segnala la lacuna finché sistemarla non diventa costoso.
Il GDPR in Europa. L’HIPAA negli Stati Uniti. L’MDR per tutto ciò che riguarda la classificazione come dispositivo medico. Requisiti di residenza dei dati che variano da Paese a Paese. Flussi di consenso che non sono semplici scelte di UX ma architettura legale. Audit trail che non sono una richiesta di funzionalità ma un obbligo normativo.
Un’agenzia di sviluppo generalista può realizzare un prodotto funzionante. Ciò che di solito non sa fare è prendere fin dal primo giorno le scelte di architettura giuste per restare conformi mentre si cresce, integrarsi senza problemi con i sistemi EHR a cui dovrete collegarvi al diciottesimo mese e produrre la documentazione richiesta da una verifica normativa che non sapevate sarebbe arrivata.
Il problema non è che le agenzie generaliste siano scarse. Il problema è che non sanno cosa non sanno della sanità, e nemmeno la maggior parte dei founder healthtech alla prima esperienza. Così nessuno segnala la lacuna finché sistemarla non diventa costoso.
La compliance non è una checklist da spuntare alla fine. È una scelta di architettura da fare all’inizio. Sbagliarla non costa solo denaro: può far chiudere l’azienda.
Le 3 decisioni che distinguono le startup healthtech che sopravvivono
Decisione 1: hanno trattato la compliance come architettura, non come burocrazia
Le startup healthtech che crescono non aggiungono la compliance a un prodotto finito. La integrano nelle fondamenta (architettura dei dati, flussi di consenso, controllo degli accessi, audit log, accordi con i fornitori) fin dal primo sprint.
Questo conta per due motivi. Il primo è normativo: un prodotto costruito senza privacy by design non supera un audit GDPR, perde contratti enterprise che richiedono documentazione di compliance e affronta costi di correzione molto superiori a quanto sarebbe costato farlo bene dall’inizio.
Il secondo è commerciale: i grandi acquirenti del settore sanitario (ospedali, assicurazioni, reti di cliniche) hanno processi di acquisto che includono una due diligence tecnica. Se la vostra architettura dei dati non sa rispondere a domande di base su dove si trovano i dati dei pazienti, come sono cifrati in transito e a riposo e qual è il modello di controllo degli accessi, il contratto non si chiude. Non perché l’acquirente faccia il difficile, ma perché per legge deve chiederlo.
I founder che superano il Series A sono quelli il cui partner di sviluppo ha posto queste domande prima di scrivere una sola riga di codice.
Questo conta per due motivi. Il primo è normativo: un prodotto costruito senza privacy by design non supera un audit GDPR, perde contratti enterprise che richiedono documentazione di compliance e affronta costi di correzione molto superiori a quanto sarebbe costato farlo bene dall’inizio.
Il secondo è commerciale: i grandi acquirenti del settore sanitario (ospedali, assicurazioni, reti di cliniche) hanno processi di acquisto che includono una due diligence tecnica. Se la vostra architettura dei dati non sa rispondere a domande di base su dove si trovano i dati dei pazienti, come sono cifrati in transito e a riposo e qual è il modello di controllo degli accessi, il contratto non si chiude. Non perché l’acquirente faccia il difficile, ma perché per legge deve chiederlo.
I founder che superano il Series A sono quelli il cui partner di sviluppo ha posto queste domande prima di scrivere una sola riga di codice.
Decisione 2: hanno scelto un partner di sviluppo che capisce come acquista il settore sanitario
C’è un tipo di conoscenza specifico che distingue i team di sviluppo con esperienza nella sanità da tutti gli altri: sanno che chi usa il vostro prodotto non è quasi mai chi lo compra.
Nel software consumer, utente e acquirente sono di solito la stessa persona. Nell’healthtech, un medico usa il prodotto, un responsabile di reparto lo valuta, una commissione acquisti lo approva, un team IT lo integra e un responsabile della compliance dà il via libera. Ognuna di queste persone ha preoccupazioni diverse e un diverso potere di veto.
Un partner di sviluppo che ha già realizzato prodotti sanitari sa che la UX deve servire il clinico, l’architettura API deve soddisfare l’IT, il modello dei dati deve superare la verifica di compliance e il flusso di onboarding deve essere abbastanza semplice per un responsabile di struttura già sovraccarico di lavoro.
Un partner senza questa esperienza vi costruirà qualcosa che funziona dal punto di vista tecnico e fallisce da quello commerciale, perché è stato pensato per una sola persona in un processo d’acquisto che ne coinvolge sei.
Nel software consumer, utente e acquirente sono di solito la stessa persona. Nell’healthtech, un medico usa il prodotto, un responsabile di reparto lo valuta, una commissione acquisti lo approva, un team IT lo integra e un responsabile della compliance dà il via libera. Ognuna di queste persone ha preoccupazioni diverse e un diverso potere di veto.
Un partner di sviluppo che ha già realizzato prodotti sanitari sa che la UX deve servire il clinico, l’architettura API deve soddisfare l’IT, il modello dei dati deve superare la verifica di compliance e il flusso di onboarding deve essere abbastanza semplice per un responsabile di struttura già sovraccarico di lavoro.
Un partner senza questa esperienza vi costruirà qualcosa che funziona dal punto di vista tecnico e fallisce da quello commerciale, perché è stato pensato per una sola persona in un processo d’acquisto che ne coinvolge sei.
Decisione 3: hanno progettato per l’integrazione fin dal primo giorno, non come ripensamento
I prodotti healthtech isolati sono sempre più rari. Il mercato si è consolidato attorno a ecosistemi (piattaforme EHR, sistemi di patient engagement, infrastrutture di fatturazione, reti di laboratori) e ci si aspetta che i nuovi prodotti vi si colleghino.
L’integrazione con gli EHR da sola è uno dei requisiti tecnicamente più impegnativi del software sanitario. Gli standard HL7 e FHIR esistono proprio per rendere possibile questa interoperabilità, ma implementarli correttamente richiede un’esperienza che la maggior parte degli sviluppatori generalisti non ha. Sbagliare non ritarda solo una funzionalità: può bloccare del tutto un contratto enterprise, perché l’ospedale non adotterà un software che non si collega alla sua infrastruttura esistente.
Le startup che sopravvivono progettano pensando all’integrazione fin dall’inizio. La loro architettura API è pensata per connettersi. I loro modelli di dati sono mappati sugli standard di settore. Il loro partner di sviluppo l’ha già fatto e sa dove si nascondono i casi limite.
Quelle che non sopravvivono spesso scoprono questo requisito dopo diciotto mesi, quando il primo grande potenziale cliente chiede un’integrazione EHR e la risposta è una ricostruzione di tre mesi.
L’integrazione con gli EHR da sola è uno dei requisiti tecnicamente più impegnativi del software sanitario. Gli standard HL7 e FHIR esistono proprio per rendere possibile questa interoperabilità, ma implementarli correttamente richiede un’esperienza che la maggior parte degli sviluppatori generalisti non ha. Sbagliare non ritarda solo una funzionalità: può bloccare del tutto un contratto enterprise, perché l’ospedale non adotterà un software che non si collega alla sua infrastruttura esistente.
Le startup che sopravvivono progettano pensando all’integrazione fin dall’inizio. La loro architettura API è pensata per connettersi. I loro modelli di dati sono mappati sugli standard di settore. Il loro partner di sviluppo l’ha già fatto e sa dove si nascondono i casi limite.
Quelle che non sopravvivono spesso scoprono questo requisito dopo diciotto mesi, quando il primo grande potenziale cliente chiede un’integrazione EHR e la risposta è una ricostruzione di tre mesi.
Cosa chiedere davvero a un partner di sviluppo prima di iniziare
La maggior parte dei founder healthtech valuta i partner di sviluppo in base a portfolio, prezzo e stile di comunicazione. Contano. Ma nella sanità non bastano. Ecco le domande che fanno davvero la differenza:
Avete già sviluppato prodotti conformi a GDPR o HIPAA?
Non "conoscete il GDPR", ma avete sviluppato per esserne conformi? Chiedete un esempio concreto. Chiedete quali scelte di architettura hanno fatto per questo motivo. Un team con esperienza reale risponderà nel dettaglio: scelte sulla residenza dei dati, standard di cifratura, gestione del consenso. Un team senza esperienza risponderà in modo generico.
Come gestite l’integrazione HL7 o FHIR?
Se la risposta è "ci informeremo quando servirà", quella è la vostra risposta. I team con esperienza nella sanità hanno un’opinione su questo prima ancora che lo chiediate. Hanno già risolto i problemi che state per incontrare.
Com’è il vostro processo di documentazione per i prodotti regolamentati?
Pratiche normative, verifiche negli acquisti enterprise e due diligence degli investitori richiedono documentazione tecnica che la maggior parte dei progetti non produce di default. Chiedete se la documentazione fa parte della consegna standard o è un extra. La risposta vi dice come pensano al prodotto oltre il codice.
Di chi è la proprietà intellettuale e cosa succede se ci separiamo?
Nella sanità la continuità non è facoltativa. Se il vostro partner di sviluppo sparisce, viene acquisito o smette di rispondere, dovete poter affidare il codice a un altro team senza perdere mesi per recuperare. Assicuratevi che gli accordi siano espliciti su proprietà intellettuale, standard di documentazione del codice e processo di passaggio di consegne.
Il problema dei finanziamenti è un sintomo, non la causa
Quando le startup healthtech finiscono la runway, il racconto riguarda di solito il clima dei finanziamenti. E sì, il venture capital si è ridotto, i deal sono calati e gli investitori sono più selettivi.
Ma dietro molti round falliti c’è un prodotto che non ha superato la due diligence tecnica. Un’architettura di compliance che non ha retto all’esame degli investitori. Un’integrazione EHR a tre mesi dall’essere pronta quando sono finiti i soldi. Un codice che un nuovo CTO ha esaminato definendolo da ricostruire, non da rifattorizzare.
Il 54% che sopravvive non è necessariamente più finanziato o meglio promosso. Ha preso prima decisioni migliori sull’infrastruttura, spesso perché ha scelto un partner di sviluppo che aveva già lavorato nella sanità e sapeva cosa stava per arrivare.
Ma dietro molti round falliti c’è un prodotto che non ha superato la due diligence tecnica. Un’architettura di compliance che non ha retto all’esame degli investitori. Un’integrazione EHR a tre mesi dall’essere pronta quando sono finiti i soldi. Un codice che un nuovo CTO ha esaminato definendolo da ricostruire, non da rifattorizzare.
Il 54% che sopravvive non è necessariamente più finanziato o meglio promosso. Ha preso prima decisioni migliori sull’infrastruttura, spesso perché ha scelto un partner di sviluppo che aveva già lavorato nella sanità e sapeva cosa stava per arrivare.
Le startup che sopravvivono non smettono di avere problemi difficili. Hanno solo costruito fondamenta in grado di reggerli.
Come lavoriamo con i founder healthtech
Abbiamo sviluppato prodotti sanitari in telemedicina, gestione dei pazienti, automazione dei flussi clinici e piattaforme di dati sanitari. Sappiamo come si presenta un’architettura conforme al GDPR fin dal primo sprint, come strutturare i modelli di dati per l’integrazione EHR prima che diventi urgente e come produrre la documentazione tecnica che acquirenti enterprise e investitori chiedono davvero.
Non siamo il partner giusto per ogni progetto healthtech. Ma se state costruendo qualcosa in cui compliance, integrazione e architettura contano fin dal primo giorno (e nella sanità contano sempre), vale la pena parlarne prima di iniziare, non dopo il primo audit.
Non siamo il partner giusto per ogni progetto healthtech. Ma se state costruendo qualcosa in cui compliance, integrazione e architettura contano fin dal primo giorno (e nella sanità contano sempre), vale la pena parlarne prima di iniziare, non dopo il primo audit.
