Developer explores alternatives to centralized cloud backends for user data ownership

In a recent reflection published on October 26, 2026, developer Brandon outlines the significant architectural challenges involved in creating web applications that prioritize user data ownership. The author describes an attempt to build Cheapskate, a financial tracking tool, without relying on centralized backend-as-a-service providers like Supabase. The core tension identified is between providing seamless, cross-device functionality and ensuring that sensitive personal data remains exclusively under the user’s control rather than stored on a vendor’s servers.

What happened

The author began developing Cheapskate with the intention of avoiding the standard practice of handing off authentication and database management to third-party services. While acknowledging the convenience of tools like Supabase for handling boilerplate infrastructure, the developer argued that the model is fundamentally flawed for applications dealing with sensitive financial information. The central question posed was whether it is possible to deliver the same level of durability, cross-device synchronization, and sharing capabilities found in modern cloud stacks while keeping data local to the user.

To answer this, the developer systematically evaluated several technical approaches that claim to support local-first or user-owned data models. Each option was tested against specific criteria: ease of implementation, cross-device accessibility, sharing capabilities, and browser support. The investigation revealed that most existing solutions force a compromise, either locking users into specific ecosystems, lacking mature collaboration features, or requiring technical knowledge far beyond what typical end-users possess. The conclusion was that no current off-the-shelf solution adequately replaces the convenience of centralized SQL databases for this specific use case.

Key details

• localStorage: Rejected because it does not support data access across multiple devices or allow sharing with other users.
• showDirectoryPicker: Dismissed due to incomplete browser support and the need for external services like Dropbox to handle file sharing.
• CloudKit Private Database: Ruled out because it requires Apple single sign-on, a paid developer subscription, and lacks JavaScript library support for sharing.
• SQLite in Google Drive: Found to be technically miserable to set up for both developers and users, while also enforcing Google account dependency.
• Bring-your-own DynamoDB: Considered functional but impractical, as asking users to manage AWS keys for login is unreasonable.
• remoteStorage and CRDTs: Identified as promising concepts but currently lacking mature tooling for collaboration and clear privacy guarantees.

Background

Backend-as-a-Service (BaaS) platforms like Supabase have become standard in modern web development because they abstract away complex infrastructure tasks. They provide managed authentication, real-time databases, and storage, allowing developers to focus on frontend logic. However, this convenience comes with a trade-off: the service provider hosts and controls the underlying data. For applications handling non-sensitive data, this is rarely an issue. For financial or health-related apps, some developers and users prefer a model where data resides on devices controlled by the individual, often referred to as "local-first" or "user-owned" architecture.

Local-first software aims to keep data on the user’s device, syncing only when necessary. Technologies like Conflict-free Replicated Data Types (CRDTs) help manage data consistency across devices without a central server acting as the single source of truth. Despite the theoretical benefits for privacy, the ecosystem for building these applications is less mature than traditional client-server models. Developers often face fragmented tooling, inconsistent browser APIs, and a lack of standardized protocols for secure, peer-to-peer collaboration.

Why it matters

For teams running self-hosted software or building products for privacy-conscious markets, this analysis highlights a critical gap in the current tooling landscape. Many organizations choose self-hosting to maintain control over their data, yet they still rely on centralized architectures within their own infrastructure. The difficulty in implementing true user-owned data models means that even privacy-focused applications often default to storing data on company servers. This creates liability and trust issues, as users must believe the operator will protect their data rather than having cryptographic or architectural guarantees that they own it.

The absence of a "Firebase for CRDTs" or a simple, universal API for user-controlled SQL queries forces developers to make difficult choices. They can either build complex custom synchronization layers, which increases maintenance burden and bug surface area, or accept the privacy compromises of centralized storage. For small and mid-sized companies, this means that offering true data sovereignty to customers is currently more expensive and technically risky than using standard cloud providers. Until the tooling matures, privacy-centric features may remain a niche capability rather than a standard offering.

What you can do

• Evaluate whether your application truly requires real-time cross-device sync before committing to complex local-first architectures.
• If using centralized storage, implement strict data retention policies and clear user consent mechanisms to mitigate privacy risks.
• Monitor the development of remoteStorage and CRDT libraries, as these ecosystems are evolving rapidly and may offer viable solutions soon.
• Consider hybrid models where sensitive data is encrypted client-side before being stored on your servers, giving users key control.
• Document your data architecture transparently for users, explaining where data lives and who has access to it.
• Engage with open-source communities working on local-first protocols to share feedback and accelerate tooling maturity.