Prodotti cloud al consumer
Design e ingegneria per prodotti cloud al consumer
Un prodotto cloud al consumer si gioca sulla fiducia. L'utente firma quando crede che i suoi file siano davvero al sicuro, e se ne va appena qualcosa lo fa dubitare. Lavoriamo perché quella fiducia regga il giorno della prima copertura stampa, il giorno del primo audit di sicurezza indipendente, la prima volta che l'app si apre in metropolitana senza rete.
Quello che vediamo più spesso
- 01
Il visitatore arriva sulla promessa di una landing e riceve un altro prodotto
La landing parla un linguaggio, il prodotto ne parla un altro. Le anteprime sembrano perfette, gli screenshot si vedono in 4K, ma chi si registra entra in un signup, un onboarding e un dashboard che non hanno avuto le stesse mani sopra. La frattura si vede al primo accesso, e si paga sulla retention dei primi mille utenti.
- 02
L'articolo stampa porta diecimila utenti in un'ora e il prodotto si scusa
Tutto regge finché gli utenti sono in early access. Poi una copertura su TechCrunch o un thread su Hacker News porta dieci, cento volte la carica in un'ora. La lista dei file ridisegna tutto a ogni interazione, la ricerca smette di rispondere, le query del database che reggevano con cinquanta utenti non reggono più. Il giorno in cui dovrebbe arrivare il fatturato, il prodotto si pianta.
- 03
Il primo audit indipendente smonta la promessa di "cifrato"
La landing dice che i dati dell'utente sono cifrati. Il primo ricercatore di sicurezza che apre il codice trova le chiavi del cifrario sul server, leggibili da chi gestisce l'infrastruttura. La differenza fra una promessa di privacy che si difende nel codice e una che si smonta al primo controllo passa di lì. Gli utenti arrivati proprio per la privacy passano alla concorrenza.
Come abbiamo costruito Cloude
Cloude è arrivato con un MVP in early access e un round in chiusura. Il founder voleva un solo team che si prendesse il sito di marketing, il prodotto web e l'app mobile dentro la stessa codebase, e voleva una promessa di privacy difendibile davanti a un ricercatore di sicurezza.
Marketing e prodotto, nello stesso codice
Quasi tutti i prodotti cloud al consumer convivono con una frattura. Il sito di marketing vive in un repository, il prodotto in un altro, e in mezzo c'è una traduzione che nessuno ha davvero voglia di mantenere. Al lancio, marketing e ingegneria escono in eventi separati, e il visitatore vede una preview che non corrisponde al prodotto che riceve al signup.
Abbiamo difeso una sola codebase Next.js, un solo design system, un solo team. Il founder ha sposato la scelta. Il prezzo è che una modifica di copy richiede un coordinamento con il deploy, e chi rifattorizza un componente deve pensare anche alla SEO. Il guadagno è che il componente Files che il visitatore vede sulla landing è quello vero del prodotto. Al signup non c'è scarto. Il trimestre del lancio è uscito in un solo evento, e la retention sui primi mille utenti non si è giocata sulla disillusione.
Ingegneria per il giorno del TechCrunch
Il seed deck proiettava un ordine di grandezza in più di utenti nei dodici mesi successivi. Abbiamo lavorato per la proiezione a dodici mesi.
La lista dei file disegna un numero fisso di righe a schermo, e il browser fa la stessa fatica con mille o con un milione di voci. I file recenti arrivano da una sola query del server, indicizzata sulle colonne che servono. La cache locale del browser legge prima dal disco, e la prima schermata appare prima che la rete risponda. Quando il telefono passa dal Wi-Fi alla rete cellulare, la connessione resta in piedi senza ricominciare la negoziazione. Il giorno della prima copertura stampa il prodotto ha tenuto. Non per fortuna.
Mobile nativo, perché serve davvero
La scorciatoia era una PWA chiusa dentro una WebView. Abbiamo scelto il nativo. Non per stile, ma perché in un prodotto di privacy le chiavi del cifrario devono vivere nella zona protetta del telefono, e una WebView non ci arriva. Il client mobile è scritto in React Native sul design system del web, così una modifica di token arriva su tutti i client allo stesso momento. La build sta sotto la soglia oltre la quale Apple e Google smettono di scaricare gli aggiornamenti in background, e le nuove versioni arrivano sul telefono dell'utente senza che debba aprire lo store.
La promessa di privacy si verifica
La cifratura sul dispositivo spesso si paga in latenza: cold start più lunghi, file che si aprono più piano, viaggi in più sulla rete. Quel costo, nei casi che abbiamo visto, non viene dalle operazioni di cifratura. Viene da scelte di architettura che si possono evitare se le pensi prima.
I file vengono cifrati sul dispositivo prima di partire. Le chiavi del cifrario derivano dalla passphrase scelta dall'utente, e sul server non vivono mai. Le chiavi private restano nella zona protetta del telefono, e non si estraggono nemmeno da un dispositivo modificato. Sul server arrivano blob illeggibili, e nessuno dell'infrastruttura vede mai una chiave decifrata.
Un audit di sicurezza indipendente gira con cadenza ricorrente sull'intera architettura. Il programma di disclosure dichiara i tempi di risposta a chi segnala una vulnerabilità, e ogni segnalazione viene seguita fino alla chiusura. Quando un giornalista o un compliance officer chiede di vedere cosa c'è sotto, il cliente non legge una nostra promessa: legge un report scritto da qualcun altro.
Cosa restituisce questa scelta
Dopo il lancio, quando il founder ha voluto aggiungere una piattaforma in più, una nuova forma di condivisione, una pagina nuova nel report di trasparenza, è stato un cambio in un solo repository, non un coordinamento fra tre team. Il design system è il contratto fra il marketing e il prodotto, e il contratto regge.
Cosa portiamo in produzione, in questo settore
- 01
Quello che il visitatore vede sulla landing è quello che riceve al signup
Il sito di marketing e il prodotto condividono codice e design system. Il componente che il visitatore vede in anteprima sulla landing è quello vero del prodotto. Al signup non c'è scarto fra la promessa e quello che gli arriva sotto le mani, e i primi mille utenti non pagano la retention della disillusione.
- 02
Cifratura che un audit indipendente verifica
I file vengono cifrati sul telefono o sul computer dell'utente, con chiavi che dal dispositivo non escono. Sul server arrivano blob illeggibili, anche per chi gestisce l'infrastruttura. Un audit di sicurezza indipendente firma il report. Il cliente legge il report dell'auditor.
- 03
Pronto al giorno in cui l'articolo porta diecimila utenti
Il prodotto regge la crescita che il founder ha promesso agli investitori al seed, non solo la coorte di early access che lo usa oggi. La lista dei file resta fluida con mille o con un milione di voci. Le query non rallentano mentre il dataset cresce. Quando arriva l'ondata, l'utente non aspetta.
- 04
App mobile nativa, perché serve davvero
Per un prodotto di privacy le chiavi del cifrario devono vivere nella zona protetta del telefono, quella che Apple e Google riservano alle credenziali biometriche. Una WebView non la vede. Il client mobile è scritto in React Native sullo stesso design system del web, così una modifica di token raggiunge tutti i client allo stesso momento.
- 05
Sync che resiste alla galleria della metro
Il prodotto continua a leggere e scrivere mentre il telefono è offline. Quando la rete torna, ripropaga soltanto le modifiche reali. Una pausa offline lunga non si trasforma in un'ora di sincronizzazione al rientro.
- 06
Una posizione onesta sulla passphrase persa
Se l'utente perde la passphrase, i suoi dati sono persi. Lo diciamo al primo accesso, in chiaro, non in fondo a una pagina di help. Chi vuole un percorso di recupero lo attiva esplicitamente, frazionato in pezzi che sul server non vivono mai insieme. Niente backdoor mascherate da prodotto privato.
Un'architettura che si dimostra invece di chiedere fiducia
Lo stack di un prodotto cloud al consumer non si valuta sulla demo del founder. Si valuta in due momenti della vita del prodotto: il giorno in cui gli utenti crescono di un ordine di grandezza, e il giorno in cui un ricercatore di sicurezza, un giornalista o un compliance officer chiede di vedere come funziona davvero. Lavoriamo perché lo stack vinca soprattutto il secondo momento.
Sito di marketing e prodotto sono lo stesso codice. Per il founder questo significa che la landing non promette quello che il prodotto non mantiene, e che quando il prodotto cambia la landing cambia con lui, senza un ticket fra due team. Per il visitatore significa che il signup gli consegna il prodotto che la pagina stava vendendo.
Il client mobile è un'app nativa. Per un prodotto di privacy non è una preferenza, è un requisito: le chiavi del cifrario devono stare dentro la zona protetta del telefono, e una WebView non la raggiunge. Scriviamo in React Native sul design system del web, così una modifica di token arriva su tutti i client allo stesso momento. Le build restano sotto la soglia oltre la quale Apple e Google smettono di scaricare gli aggiornamenti in background, e le nuove versioni arrivano sul telefono dell'utente senza che debba aprire l'app dello store.
I file vengono cifrati sul dispositivo prima di partire. La chiave di cifratura deriva dalla passphrase scelta dall'utente, e sul server non ci vive mai. Sul server arrivano blob illeggibili, anche per chi gestisce l'infrastruttura. La frase "non possiamo leggere i tuoi dati" smette di essere una frase di marketing. Sta scritta nel codice.
Il prodotto regge la scala promessa al seed, non solo la coorte di oggi. La lista dei file resta fluida a qualunque dimensione, perché il browser disegna soltanto le righe che sta mostrando davvero. Le query del percorso caldo arrivano da colonne indicizzate, con un piano di esecuzione che regge mentre il dataset cresce. La cache locale del browser fa apparire la prima schermata prima che la rete risponda.
Un audit di sicurezza indipendente gira con cadenza ricorrente sull'intera architettura. Il programma di disclosure dichiara i tempi di risposta a chi segnala una vulnerabilità, e ogni segnalazione viene seguita fino alla chiusura. Quando un giornalista o un compliance officer chiede di vedere cosa c'è sotto, il cliente non legge una nostra promessa: legge un report scritto da qualcun altro.
Domande frequenti in questo settore
Come fate a dire "cifrato" senza che la prima auditoria lo smonti?+
I file vengono cifrati sul dispositivo dell'utente prima di entrare in rete. La chiave di cifratura deriva dalla passphrase scelta dall'utente, e sul server non ci vive mai. Sul server arrivano blob illeggibili, e nessuno dell'infrastruttura vede mai una chiave decifrata. Un audit di sicurezza indipendente verifica tutto questo con cadenza ricorrente, e firma un report che il cliente legge per conto suo.
Perché un'app mobile nativa e non una PWA in WebView?+
La zona protetta del telefono, quella che Apple e Google riservano alle chiavi e alle credenziali biometriche, non si raggiunge da un sito chiuso dentro una WebView. Per un prodotto di privacy, è là che devono vivere le chiavi del cifrario. Il client mobile è scritto in React Native e prende il design system dallo stesso pacchetto che usa il web, così la scelta del nativo si paga una volta sola sul sistema dei token.
La cifratura sul dispositivo non rallenta il prodotto?+
Il costo di latenza che molti prodotti pagano sulla cifratura sul dispositivo viene da scelte di architettura, e solo in piccola parte dalle operazioni di cifratura. Apriamo un file condiviso alla stessa velocità di uno privato, perché la negoziazione delle chiavi resta abbastanza leggera da non farsi sentire nel primo caricamento.
E se l'utente perde la passphrase?+
Se l'utente perde la passphrase, i suoi dati sono persi. Lo diciamo al primo accesso, in chiaro, non in fondo a una pagina di help. Chi vuole un percorso di recupero lo attiva esplicitamente, frazionato in pezzi che sul server non vivono mai insieme. Niente backdoor mascherate da prodotto privato.
Come si tiene la scala prima che gli utenti arrivino davvero?+
La lista dei file disegna un numero fisso di righe a schermo, e il browser fa la stessa fatica con mille o con un milione di voci. Le query del percorso caldo arrivano da colonne indicizzate, con un piano di esecuzione che regge mentre il dataset cresce. La prima schermata si carica dalla cache locale del browser, e l'utente non aspetta la rete per cominciare a lavorare.