The Power of Privacy: How Ephemeral Backends Make Our Products Harder to Breach

Problem

The standard architecture for a data product concentrates risk by default. Users upload their financial records into a central database, and that database grows into two things at once: the most valuable asset the company owns, and the largest concentration of sensitive customer information it holds.

From that point on, security is a continuous obligation with no finish line. Every additional dependency, credential, and endpoint increases operational risk, and because all customers share one store, the impact of a single compromise extends to the entire customer base.

The exposure runs in both directions. Users risk their data; the operator takes on everything attached to holding it: breach disclosure obligations, regulatory liability, subpoena scope, insider risk, and the ongoing operational burden of acting as custodian for thousands of people's bank records.

For a small team shipping consumer and business finance products, that risk profile is a business constraint before it is a technical problem.

Challenge

The simplest mitigation, collecting nothing, is not available to products whose entire value is analyzing the user's data. Aegis BI has to compute forecasts over a company's ledger. MyBudgetNerd has to parse and categorize real bank statements. Thera has to maintain a detailed profile of a contractor's capabilities and pricing history.

The challenge was to deliver that analysis while refusing, structurally, to become a warehouse of the underlying data.

And it had to be structural. A privacy policy is a promise that can drift with every release; we wanted claims that are enforced by the architecture itself, so the honest answer to "where does our data go?" is short, checkable, and independent of anyone's discipline.

It helps to be precise about terms here. Privacy and security are related but distinct goals: privacy determines what information should be collected and who may access it; security determines how that information is protected against unauthorized access. Most architectures treat them as separate workstreams. By minimizing the amount of customer data that exists in the first place, one architectural decision strengthens both: there is less to govern, and less to defend.

Solution

Across the product line, the backend is ephemeral: it computes on data while a request is in flight and holds none of it afterward. Each product applies the principle at a different point on the spectrum, because each has different constraints.

Aegis BI holds the working dataset on the user's machine. Uploaded workbooks are parsed in-session and stored in the browser's on-device database (IndexedDB); the backend is a stateless calculator. When a dashboard computes or an AI agent runs, the dataset travels with the request, is processed, and is discarded.

Multiple companies can use one Aegis deployment without their data ever mixing, because no server-side copy exists to mix.

MyBudgetNerd processes statements server-side but request-by-request, in memory. A PDF is parsed, transactions are extracted and categorized, results return to the device, and nothing is retained as a customer dataset. There are no bank logins at all. Users import statements they already have, so the product never touches a bank credential. Any history the user wants kept lives on their own device, with a retention window they choose, down to "off".

Thera, our capture-intelligence platform, is the case where persistence is genuinely required; a Digital Twin only works if it lives somewhere. There, the principle becomes legibility instead of statelessness: one server, three containers, one SQLite database file.

Every piece of Thera customer data can be enumerated from that single database, with nothing scattered across cloud services and no third-party analytics. The database sits on its own encrypted volume with managed daily snapshots, and a separate nightly encrypted, auto-expiring copy is written off-server. Both exist for disaster recovery; neither is a second home for the data. Each organization's learning loop runs inside its own boundary, and the engine never reads another customer's records.

Thera has since grown the one thing this architecture has to handle carefully: a feature that is deliberately cross-organization. Its partner network lets a member publish a listing that other members' searches can return. The principle survives by being explicit rather than absent. A listing exists only if its owner creates it, carries only the fields they filled in, and is withdrawn from every search the moment they unpublish. It is a separate record from the Digital Twin, so nothing about a company's pipeline, scores, or drafts can cross into it. Sharing that is chosen and bounded is not the same failure as sharing that is incidental.

Technical Implementation

The implementation reduces to three recurring themes: where data is allowed to rest, what the AI layer is allowed to see, and how much infrastructure exists to defend.

The AI layer gets the same treatment as storage, because model calls are the other path by which user data can leave the system. In every product, AI is opt-in, payloads are minimized, and external calls are outbound-only, made on an explicit user action.

Results

The clearest way to state the security result is as a set of architectural properties, stated as facts about the system rather than performance claims:

• Zero persistent customer datasets on the Aegis BI backend
• Zero stored bank credentials anywhere in the product line
• Zero cross-customer financial databases
• User-controlled retention in MyBudgetNerd, down to no retention at all
• One SQLite database as Thera's entire customer-data footprint
• Two encrypted backup layers, both daily, both expiring automatically
• No PII or request bodies sent to monitoring systems
• Stateless, request-by-request processing in Aegis BI and MyBudgetNerd

These properties have direct operational consequences. The worst-case outcome of a compromised Aegis BI or MyBudgetNerd backend is bounded, because the server holds no accumulated user data to exfiltrate; an attacker who reaches the backend finds compute, not a dataset. The attack surface that matters, the set of places where customer data rests, is smaller by construction rather than by policy.

Minimization also removed entire categories of operational work. Encryption-at-rest schemes for a central statement store, access audits over that store, retention and deletion tooling: none of these had to be built, so none of them can fail or drift. Auditing reduces to enumerating what exists, and for Thera, disaster recovery planning reduces to restoring a single encrypted file.

Customer-facing processes shorten for the same reason. A security review can trace the complete data flow in one sitting, compliance discussions start from what is never collected, and the scope of any subpoena or disclosure obligation is limited to data that actually exists. Insider risk shrinks in parallel: operators cannot browse records the system never stores.

Finally, the architecture is a trust result. "Your data stays in your browser; the backend stores nothing" is a one-sentence answer to the hardest enterprise objection, and it is verifiable rather than contractual. MyBudgetNerd's App Store reviews cite the privacy-conscious design specifically, evidence that users notice the difference between a policy and an architecture.

Lessons Learned

Data you don't hold is data you can't lose. Minimization beats mitigation: every security control we didn't have to build is a control that can't fail, and absent data can't be exfiltrated, mis-logged, or subpoenaed.

Privacy must be architecture, not policy. A promise in a privacy page can drift with any release; a backend with no database cannot. Making the claims structural is what makes them durable, and what makes them credible to the people most skeptical of data products.

When persistence is unavoidable, make it legible. Thera taught us the complement to statelessness: if you must hold customer data, hold it somewhere you can point to: one file, one server, enumerable in a single table. Knowing precisely where every byte lives is itself a security property.

The same discipline applies to AI calls. Model APIs are a data egress path like any other; opt-in gating, sanitized minimal payloads, and guards that keep models from generating the numbers extend the ephemeral-backend principle into the AI layer.

The broader lesson is that data minimization is a design principle, not a compliance checkbox. Every system we design begins with the same questions:

• Does this data need to exist?
• Does it need to leave the user's device?
• If it must exist, how long should it exist?
• Can we reduce the amount collected?
• Can we make its storage location explicit and understandable?

The answers differ across Aegis BI, MyBudgetNerd, and Thera, but the questions never change. Privacy-first architecture is not a feature to list on a pricing page; it is an engineering discipline, applied at design time, that determines what a system can leak long before anyone has to defend it. You can't leak what you never stored.