Design and engineering for consumer cloud products
A consumer cloud product runs on trust. Users sign up when they believe their data is safe, and they walk the moment something makes them doubt. We work so the trust holds the day the press piece brings ten thousand users in an hour, the day a security researcher reviews the code, the day the app opens in a tunnel without a network.
The problems we hear most
Visitors land on the landing's promise and get a different product
The landing speaks one language, the product speaks another. The previews look clean, the screenshots ship in 4K, and then someone signs up and walks into a signup, an onboarding and a dashboard that have not been touched by the same hands. The fracture shows on first use, and the bill arrives on the retention of the first thousand users.
The press piece brings ten thousand users in an hour and the product apologises
Everything holds while users are in early access. Then a TechCrunch piece or a Hacker News thread pushes ten or a hundred times the load through the app in an hour. The file list re-renders the DOM on every keystroke, search stops responding, the queries that held with fifty users do not hold anymore. On the day the revenue should have arrived, the product gives way.
The first security researcher takes the "encrypted" claim apart
The landing reads "encrypted". The first researcher who opens the code finds the keys living on the server, readable by anyone running the infrastructure. The difference between a privacy claim that holds under inspection and one that doesn't lives right there. The users who came for privacy walk to the alternative.
Cloude, the case
Cloude is a consumer cloud product across web, desktop and mobile. We designed and wrote it inside one repository, with the same design voice running between the marketing site and the product. The privacy claim isn't a positioning line. Files are encrypted on the user's device, and an independent security audit signs a report the customer reads for themselves.
How we built Cloude
Cloude came in with an MVP in early access and a round about to close. The founder wanted one team to take the marketing site, the web product and the mobile app inside one codebase, and wanted a privacy claim that could defend itself in front of a security researcher.
Marketing and product, same code
Most consumer cloud products live with a fracture. The marketing site lives in one repo, the product in another, and in the middle there's a translation layer nobody really wants to maintain. At launch, marketing and engineering ship in separate events, and the visitor sees a preview that doesn't match the product they receive on signup.
We argued for one Next.js codebase, one design system, one team. The founder backed the call. The price is that a copy change costs a coordination with the deploy, and a component refactor has to account for SEO. The return is that the Files component the visitor sees on the landing is the real one from the product. On signup, there's no gap. The launch quarter shipped in a single event, and the retention on the first thousand users wasn't spent on disillusion.
Engineering for the TechCrunch day
The seed deck projected an order-of-magnitude jump in users over the next twelve months. We built for the projection, not for the load of the moment.
The file list renders a fixed number of rows on screen, so the browser does the same work with a thousand entries or a million. Recent files come from a single server query, indexed on the columns that matter. The local browser cache reads from disk first, and the first paint shows up before the network responds. When the phone switches from Wi-Fi to cellular, the connection survives without restarting the handshake. The day the first press piece dropped, the product held. Not by luck.
Native mobile, because it has to be
The shortcut was a PWA wrapped in a WebView. We went native. Not for style, but because in a privacy product the encryption keys have to live inside the secure area of the phone, and a WebView can't reach it. The mobile client is React Native on the web's design system, so a token change reaches every client at once. The build stays under the threshold where Apple and Google keep delivering silent background updates, and new versions arrive on the phone without the user having to open the store app.
Privacy that gets verified
On-device encryption often shows up in the latency bill: longer cold starts, files that open more slowly, more trips on the wire. That cost, in the cases we've seen, doesn't come from the encryption operations. It comes from architecture choices that are avoidable if you think about them up front.
Files are encrypted on the device before they leave it. The keys derive from the passphrase the user picks, and they never live on the server. Private keys stay inside the secure area of the phone, and they don't come out on a modified device. The server only holds opaque blobs, and no one on the infrastructure sees a decrypted key.
An independent security audit runs against the architecture on a recurring cadence. The disclosure programme spells out response times to anyone reporting a vulnerability, and every report is tracked through to closure. When a journalist or a compliance officer asks to see what's under the hood, the customer doesn't read our promise. They read a report written by someone else.
What the choice gives back
After launch, when the founder wanted to add a new platform target, a new sharing model, a new page in the transparency report, that was a change in a single repository, not a coordination across three teams. The design system is the contract between the marketing and the product, and the contract holds.
What we deliver for this vertical
What a visitor sees on the landing is what they get on signup
The marketing site and the product share code and a design system. The component a visitor previews on the landing is the real one from the product. The signup hands over what the landing was selling, and the first thousand users don't pay the retention cost of disillusion.
Encryption that gets verified, not just believed
Files are encrypted on the user's phone or laptop, with keys that never leave the device. The server only holds opaque blobs, unreadable by the people who run the infrastructure. An independent security audit signs the report. The customer reads the report, not the marketing line.
Ready for the press-piece day, not just the early-access cohort
The product holds the growth the founder promised the seed round, not just today's hundred users. The file list stays fluid with a thousand entries or a million. Queries don't slow down as the dataset grows. When the wave arrives, the user doesn't wait.
A native mobile app, because it has to be
For a privacy product, the encryption keys have to live inside the secure area of the phone, the area Apple and Google reserve for biometric credentials. A WebView can't reach it. The mobile client is React Native on the same design system as the web, so a token change reaches every client at once.
Sync that survives the subway tunnel
The product keeps reading and writing while the phone is offline. When the network comes back, it propagates only the changes the user actually made. A long offline window doesn't turn into a long sync on return.
An honest position on a lost passphrase
If a user loses their passphrase, their data is gone. We say so at first sign-in, in plain words, not at the bottom of a help page. Recovery is opt-in, split across pieces that never live together on the server. No backdoor dressed up as a private product.
An architecture that proves itself instead of asking for trust
A consumer cloud stack doesn't get judged on the founder's demo. It gets judged in two moments of the product's life: the day the user count climbs an order of magnitude, and the day a security researcher, a journalist or a compliance officer asks to see how it actually works. We pick the stack that wins the second one.
The marketing site and the product are the same code. For the founder that means the landing never promises what the product can't keep, and that when the product changes the landing changes with it, without a ticket between two teams. For the visitor it means the signup hands over the product the page was selling.
The mobile client is a native app. For a privacy product this isn't a preference, it's a requirement: the encryption keys have to live inside the secure area of the phone, and a WebView can't reach it. We write in React Native on the web's design system, so a token change reaches every client at once. The build stays under the threshold where Apple and Google keep delivering silent background updates, and new versions arrive on the phone without the user opening the store app.
Files are encrypted on the device before they leave it. The encryption key is derived from the passphrase the user picks, and it never lives on the server. The server only holds opaque blobs, unreadable to the people who run the infrastructure. The "we can't read your data" line stops being marketing copy. It's in the code.
The product holds the scale the seed deck promised, not just today's cohort. The file list stays fluid at any size, because the browser renders only the rows it's actually showing. Hot-path queries come from indexed columns, with a query plan that holds as the dataset grows. The local browser cache shows the first paint before the network responds.
An independent security audit runs against the architecture on a recurring cadence. The disclosure programme spells out response times to anyone reporting a vulnerability, and every report is tracked through to closure. When a journalist or a compliance officer asks to see what's under the hood, the customer doesn't read our promise. They read a report written by someone else.
Questions founders ask
How can you say "encrypted" without the first audit taking it apart?
Files are encrypted on the user's device before they hit the network. The encryption key derives from the passphrase the user picks, and it never lives on the server. The server only holds opaque blobs, and no one running the infrastructure ever sees a decrypted key. An independent security audit verifies all of this on a recurring cadence, and signs a report the customer reads for themselves.
Why a native mobile app instead of a PWA in a WebView?
The secure area of the phone, the area Apple and Google reserve for keys and biometric credentials, isn't reachable from a site wrapped in a WebView. For a privacy product, that's where the encryption keys have to live. The mobile client is React Native and pulls the design system from the same package the web uses, so the cost of going native is paid once at the token level.
Doesn't on-device encryption slow the product down?
The latency bill most products pay for on-device encryption comes from architecture choices, and only a little from cryptographic operations. We open a shared file at the same speed as a private one, because the key negotiation is light enough that it doesn't show up in the cold start.
What if the user loses the passphrase?
If the user loses their passphrase, their data is gone. We say so at first sign-in, in plain words, not at the bottom of a help page. Recovery is opt-in, split across pieces that never live together on the server. No backdoor dressed up as a private product.
How do you hold the scale before the users actually show up?
The file list renders a fixed number of rows on screen, so the browser does the same work with a thousand entries or a million. Hot-path queries come from indexed columns, with a query plan that doesn't change as the dataset grows. The first paint loads from the local browser cache, so the user doesn't wait on the network to start working.
Tell us about your product
A call to frame the work, then an honest number in the first reply.