Sereinly: Building a "Nothing Persists" Product on Top of a Backend That Necessarily Persists Some Things

A developer building Sereinly, a privacy-focused AI product, clarified that while the service claims not to store user messages, account and usage data necessarily persist for the SaaS to function. The developer acknowledged an unverified gap in tracing the full server-side request lifecycle to confirm message content is never logged or stored, highlighting a common industry issue where privacy claims often overlook logging and third-party data retention.

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. 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. 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 . 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. 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.