T-Drive

Personal cloud storage forces a bad trade. You either pay monthly rent to Google, Apple, or Dropbox forever, or you hand them plaintext access to your most private files — photos, documents, IDs. There's no mainstream option where the files are unreadable to the provider and the storage is something you already own.

Meanwhile, most people already carry huge, effectively-free cloud storage they never use as a drive: their own Telegram account. But Telegram is a chat app, not a file system — no folders, no file-type views, no search, and no guarantee the platform can't read what you upload.

I wanted to prove that one person could turn “free storage you already own” into a real private drive: files encrypted on the device before they ever leave it, browsable like Google Drive, available on every device you own — with keys that never leave you and a backend that holds nothing but noise.

Solo, genuinely end to end. This was not a design hand-off to an engineering team — I was the team.

I framed the problem as the user researcher, scoped and sequenced the MVP as the product manager, mapped the flows — onboarding, vault setup, recovery, upload, cross-device restore — as the UX designer, built the screens as the UI designer, and wrote the Kotlin, the encryption model, and the sync architecture as the engineer. Then I switched hats again to QA/hardening — writing tests, closing data-loss paths, and making the hard scope cuts.

I'm a Product UI/UX designer by trade. I took this on to prove I can own a hard, ambiguous problem the whole way down — from “why does this hurt?” to a shipped, releasable artifact.

• Zero-knowledge by design. Files must be encrypted on-device before upload. The storage backend — and I — must never be able to read them. Privacy had to be structural, not a toggle.
• Multi-device from day one. Signing in on a new phone must rebuild the entire drive — folders, files, structure — with no central server holding the user's data.
• No rent, no lock-in. It had to run on storage the user already owns, with the user's own keys.
• Recoverable, but not by me. Losing a phone can't mean losing the vault — yet recovery can't depend on any key I hold, or the whole promise collapses.
• One person, forever. Researched, designed, built, and maintained solo — so the architecture had to stay lean, modular, and automatable.

Research first. I studied why people don't self-host and why “encrypted drive” products die on contact with real users: recovery friction and multi-device pain. That produced two non-negotiables — encryption the user never has to think about, and sync that needs no server.

Product & architecture. I scoped the MVP around a single job: “back up and browse your files privately, from any device.” I designed a 12-module Kotlin / Jetpack Compose app on a clear crypto model — a random per-file key sealed by a device vault key in the Android Keystore, files encrypted with AES-256-GCM, original filenames and metadata encrypted inside the container, and only random blob names ever visible to the storage layer.

The multi-device answer — an encrypted, regenerated index. Instead of a server, every folder or file change writes an encrypted snapshot of the drive's structure. A fresh install downloads and decrypts that snapshot to rebuild the whole library. The “server” is just the user's own encrypted data; the library is generated, never hand-maintained. Restore runs on an exportable recovery key the user saves once.

UX that hides the hard part. Onboarding is phone → code → done; the vault, key-wrapping, and recovery all happen underneath. The Drive home is a real file manager — file-type segregation (Photos, Videos, Docs, Music), folders, search, starred, trash — plus one-tap device-folder backup.

Then I hardened it. Wearing the architect/QA hat, I made writes transactional, made vault-key persistence atomic (a crash can't corrupt the one key that unlocks everything), and built streaming chunked AES-GCM (256 KiB segments) so a 500 MB video encrypts without running out of memory — validated with a crypto round-trip / tamper / truncation test suite.

• Encrypt before upload, always. The backend stores opaque blobs with random names. Privacy is a property of the architecture, not a setting a user can forget.
• Index the drive, don't host it. Cross-device sync via an encrypted, regenerated index — no infrastructure, no data custody, nothing for me to be trusted with.
• A recovery key the user owns. Restore-anywhere without me ever being able to unlock a vault. The recovery model had to sit with the user or the product would be lying about privacy.
• A drive, not a chat scroll. Turn “storage you already own” into Photos / Videos / Docs / Music tabs, folders, and search — the difference between a clever hack and something people actually use.
• Cut to keep it honest. I built, then deliberately removed, an on-device facial-recognition photo-grouping feature — it added bulk and pulled focus from the core promise (private upload + browse). Killing my own feature kept the product lean and truthful.