The Nuance in "We Don't Store Your Messages" That's Worth Being Precise About
Sereinly was marketed around a privacy promise: what you paste in doesn't get stored. I want to be precise about what that actually meant architecturally, because "we don't store anything" is a claim that's easy to overstate if you're not careful about which layer of the system you're talking about.
What definitely is stored
The product needed accounts, subscriptions, and usage limits to function as a paid SaaS. Supabase-backed auth sessions, a profiles table tracking plan type and validity, and a separate usage-tracking layer (for things like remaining session minutes on a metered plan) all persist by necessity — a subscription product can't function without knowing who's paying for what and how much they've used.
What the "no storage" claim was actually about
The claim was scoped to message content specifically — what you paste into Ely, Sera, or Milo to get help with. The architecture routed AI processing through server-side API routes rather than a client-side service calling the AI provider directly (an earlier client-side implementation was explicitly deprecated in favor of this, for security reasons).
Where my confidence gets honest
Here's where I want to be careful rather than assert more than I can verify: I can confirm the system separates account/usage data (which does persist) from the AI-processing pathway (routed server-side), and I can confirm there's a dedicated usage tracking layer that appears scoped to metering (minutes, plan status) rather than content. What I haven't directly traced is the full request lifecycle inside the server-side API routes to confirm message content is never written to a log, a database row, or a request log anywhere along that path, even transiently.
That's a meaningful gap, and I think it matters to name it rather than repeat a marketing claim with more technical confidence than I've actually verified. "We don't store your messages" is a strong, specific claim, and if I were auditing this system before making that claim publicly again, I'd want to trace the full server-side path end to end, check request/error logging configuration, and confirm no AI provider we're calling itself retains inputs on their end by default.
Why this distinction matters generally
I think this is a common gap in how privacy claims get made across the industry generally, not specific to this one product: "we don't store your data" often means "we don't store it in the primary application database," while logging infrastructure, error tracking tools, and third-party API providers can each retain data through separate paths that a simple "no storage" claim doesn't actually cover. A precise privacy claim needs to account for every layer data passes through, not just the one the product team is thinking about when they write the marketing copy.
Top comments (0)