How We Test New Features Before They Ship

If you've noticed us mention a feature is "in testing" rather than live, that's not a vague placeholder — it describes an actual step every meaningful change goes through before it reaches the product everyone relies on. Here's what that step is, and why we bother with it.

A separate environment, on purpose

Alongside the live site, we run an internal test environment — same codebase, its own separate data, not connected to real accounts or real files. New features land there first: a new file manager view, a new import path, changes to how encryption or backups behave. It gets exercised there against realistic usage before it's anywhere near a change that touches your actual vault.

Why not just ship and fix forward

Plenty of software works fine that way. Storage encrypted with a key we never see doesn't get that luxury the same way — if something breaks in a way that corrupts a file's structure or an upload path, "fix it in the next release" isn't good enough when the thing at risk is years of someone's documents and photos. Testing changes somewhere that isn't your vault first is the cheapest insurance we have against that.

What actually gets checked

• Does it work as intended — the basic functional check, done first.
• Does it break anything else — a new feature touching shared code (uploads, the encryption pipeline, folder handling) gets checked against everything that already depends on that code.
• Does it hold up at scale — a feature that's smooth with ten files needs to still be smooth with ten thousand.
• Is it actually ready, or just working — "works in a demo" and "ready for an encrypted storage product" aren't the same standard; we hold features back until they clear the second one.

What this means when you read "coming soon" here

When we write about something as in development or in testing — like a direct Google Drive import or a Desktop view for the file manager — it means exactly that: real, working, running in the test environment right now, but not yet held to the bar we set for shipping it to every account. We'd rather tell you honestly that something isn't ready than ship it early and have it be the reason you lose trust in the rest of the product.

The trade-off, honestly

This approach is slower. Features you might want today sometimes sit in testing longer than feels necessary from the outside. We think that trade-off is the right one for a product whose entire value proposition is "we can't read your files and you can trust us with them anyway" — that trust doesn't survive many corners cut on the way to shipping fast.