Why do we take it for granted that when you write an application, you must also become the custodian of your users' data?

When you build a modern web app, the data architecture follows a familiar, unchallenged pattern. The user types something into a form, a request flies across the internet, an application server processes it, and the data lands in a database that you operate.

As a developer, this feels natural. It gives you control. But it also forces a secondary role onto you that you might not actually want: a high-stakes security guard, a compliance officer, and a custodian of secrets.

Data as an asset vs. data as a liability

For years, the tech industry has repeated the mantra that data is an asset—something to be hoarded, analyzed, and locked inside a proprietary vault. If you own the database, you own the value.

But for many types of software, user data isn't an asset at all. Data is a liability.

If your core business value is solving a specific operational problem, managing a multi-tenant data store is a distracting burden. Consider the following cases:

  • You want to build a clean, focused task manager for creative teams, but you spend your weekends configuring database backups and worrying about connection pooling.
  • You write an elegant budgeting tool to help small businesses track expenses, but find yourself staring at compliance checklists, wondering if your infrastructure meets the latest regional data-residency laws.
  • You design a simple internal directory for an organization, only to realize you are now responsible for protecting their corporate directory from malicious actors.

The moment you store a user's operational history on your servers, you also inherit risk. You have to defend it against breaches, comply with evolving global privacy regulations, and manage high-availability infrastructure. You end up spending valuable engineering cycles protecting a data vault rather than improving the application itself.

Maybe custody of data isn't part of your core business?

What if we inverted the relationship? Instead of asking how to better secure the data we hold, we could ask a more fundamental question: Why are we holding it in the first place?

Unless you are building an ad-tech network or a massive behavioral profiling engine, maybe you aren't actually in the data-mining business. Some business models rely on aggregating, cross-referencing, and analyzing massive volumes of user data to sell targeted attention. The data is their product.

But if you are building an invoice generator, a project planner, or a CRM, you are in the software business, not the data-mining business. You don't need to aggregate your users' histories; you just need their client to be able to read and write records.

Moving software to the web brought massive advantages—instant updates, cross-device access, and link-sharing—but none of those advantages dictate who must operate the database.

This decoupling means the software developer and the owner of the database can exist in entirely different organizations. A software vendor can write the code and ship the updates, while the customer organization retains total administrative control over the database where the work actually lands.

Increasing the flexibility of infrastructure

Unbundling the application from the data store fundamentally increases the flexibility of web infrastructure.

When you decouple the client from a proprietary backend, you open up a radical possibility: the user chooses where their data lives. An organization or an individual brings their own database host. When they open your application, the client-side code connects directly to their infrastructure—whether that is a local server, a trusted corporate network, or an independent third-party host running a database they control.

As a developer, your operational surface area shrinks to almost nothing. You don't need a DevOps team to monitor server loads or patch server-side frameworks because you aren't running an application server. Your software becomes a clean, versioned product delivered entirely to the edge, while the customer gains the structural flexibility to host, backup, and audit their data according to their own internal policies.

Architectures like SPA MVC show that this isn't a theoretical exercise. By utilizing a lightweight WebSocket relay and leveraging the robust access controls already built into databases like MySQL and PostgreSQL, browsers can talk safely and directly to a user's own data store. The database handles authentication, data integrity, and grants; your application simply provides the interface.

When we stop treating user data as an inevitable business asset, we free ourselves from the liabilities of holding it. The developer gets to focus entirely on solving the user's problem, the infrastructure provider focuses on operating infrastructure, and the user finally gets true custody over their digital property.