Cloude: un prodotto cloud consumer, dal brand alla sicurezza
Un prodotto cloud consumer che abbiamo costruito per intero. Una sola codebase Next.js, un solo design system, un solo team su web, desktop e React Native. L'MVP è andato live in due settimane. Siamo rimasti e abbiamo costruito sopra il prodotto consumer finale, sulla stessa base, con crittografia end-to-end e chiavi protette dall'hardware al centro dell'architettura.

Abbiamo costruito Cloude per intero. L'MVP è andato live in due settimane. Il team che ci abbiamo messo è rimasto anche dopo il lancio e ha costruito il prodotto consumer finale sulla stessa base. Un solo incarico, una sola codebase Next.js, un solo design system, un solo team su web, desktop e React Native.
Cosa abbiamo costruito
- 2Settimane all'MVPDal brief firmato alla demo live
- 1CodebaseWeb, desktop, React Native, un solo design system
- TuttoScopeBrand, product, engineering, architettura di sicurezza

Una codebase, due interfacce
La prima decisione è stata strutturale. Un prodotto cloud consumer di solito rilascia sito di marketing e piattaforma da repo diversi, con team diversi e una traduzione continua fra i due. Abbiamo spinto per una sola codebase Next.js, un solo design system, un solo team. Il founder si è convinto.
Il trade-off è onesto. Una codebase unica significa che il team di marketing non rilascia copy senza coordinarsi col deploy di engineering, e il team di prodotto deve pensare alla SEO quando refattorizza un componente. Abbiamo accettato quei costi perché il vantaggio era più grande. Il sito di marketing incastona il componente Files in produzione invece di un mockup: quello che il visitatore vede sulla landing è quello che riceve quando si registra. Il lancio è andato live in un'unica data, non tre.


Ingegnerizzato per scalare prima che gli utenti esistessero
L'MVP partiva con una piccola coorte di early-access. Il deck della seed prevedeva un ordine di grandezza in più entro fine anno. Abbiamo dimensionato per la proiezione, non per il carico del momento.
La lista della libreria è virtualizzata con un cap di righe fisso indipendentemente dalla dimensione del dataset, così il costo di render resta piatto al crescere dei file. I file recenti vengono da una singola query server-side indicizzata su (owner_id, accessed_at desc), e il piano della query resta costante per ogni richiesta. Cartelle e viste recenti pescano da una cache locale-first IndexedDB tenuta in sync col server tramite un motore di sync differenziale: viaggiano in rete solo i byte cambiati. Un portatile in galleria continua a funzionare. Una riconnessione recupera in un singolo round.


Mobile è React Native, non un'app web travestita
La scorciatoia sarebbe stata una PWA dentro una WebView. Abbiamo costruito nativo. Il client React Native consuma gli stessi design token del web tramite un package condiviso, così un bump dei token si propaga a ogni interfaccia in un solo commit. Il bundle è ingegnerizzato per restare sotto la soglia di hot-fetch dello Store dopo il tree-shaking: gli aggiornamenti vengono scaricati in silenzio. Il trasporto è HTTP/3 su QUIC. Il primo frame interattivo su un Android di fascia bassa ha lo stesso costo fisso indipendentemente dalla dimensione del dataset: liste virtualizzate e query indicizzate fanno il lavoro pesante sul server, non sul dispositivo.

Crittografia senza il costo della latenza
È stata la decisione di engineering più dura. La crittografia end-to-end di solito presenta il conto: round trip extra, cold start più lunghi, file che si aprono più piano. Quel conto non l'abbiamo voluto pagare.
Lo storage è cifrato a riposo con AES-256-GCM. Le chiavi per account sono derivate via Argon2id dalla passphrase utente e non vengono mai salvate sul server. I file condivisi viaggiano cifrati end-to-end con scambio X25519. Le chiavi private risiedono nel Secure Enclave di iOS e nello StrongBox di Android, protette dall'hardware e resistenti all'estrazione anche su dispositivo rooted. L'architettura è zero-knowledge: il server tiene blob opachi e non vede mai una chiave in chiaro.
Penetration test indipendenti vengono eseguiti a cadenza regolare da una società di sicurezza esterna. Un programma di vulnerability disclosure pubblico con bounty per i ricercatori è attivo dal lancio.


Il design system che fa girare Cloude è stato costruito da zero per questo incarico e oggi gira su web, desktop e React Native. Lo manteniamo ancora noi. Il team è rimasto piccolo per tutta la durata, affiancato dalla governance ad agenti dello studio: nessuna proliferazione di contractor, nessun passaggio a fornitori. Il programma di vulnerability disclosure ereditato dal lavoro di sicurezza è ancora attivo. I design token che abbiamo rilasciato il primo giorno sono gli stessi che girano in produzione oggi.
Stack
- Next.js16
- React19
- TypeScript5
- React Native
- Postgres16
- Supabase
- Cloudflare R2
- Vercel Edge
- Sentry
- Meilisearch
“Due settimane dal brief all'MVP live. Lo studio è andato avanti e ha rilasciato il prodotto finale sulla stessa base. L'infrastruttura che hanno tirato su il primo giorno ha tenuto. Crittografia attiva di default, latenza sotto il secondo da qualunque edge. Non abbiamo mai rinegoziato lo scope.”
Operativo, oggi
- TuttoScopeDal brand all'architettura di sicurezza, un solo team
- 1CodebaseWeb, desktop, React Native, un solo set di design token
- Dal primo giornoTokenI token che abbiamo rilasciato al lancio girano ancora in produzione
Stai costruendo qualcosa che deve durare oltre la seed?
Lavoriamo con founder e team che hanno target di engineering misurabili e devono centrarli prima del round successivo. Dal brand alla sicurezza, un solo team. Scrivici.
Avvia un progetto