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

> Source: <https://dev.to/builtbyjason/sereinly-building-a-nothing-persists-product-on-top-of-a-backend-that-necessarily-persists-some-2401>
> Published: 2026-08-13 12:30:00+00:00

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