{"slug": "show-hn-write-saas-apps-where-users-control-where-their-data-is-stored", "title": "Show HN: Write SaaS apps where users control where their data is stored", "summary": "LinkedRecords, a new Backend-as-a-Service, enables SaaS applications where users control where their data is stored, offering server-enforced authorization and real-time collaboration. The platform allows customers to bring their own backend, ensuring data residency compliance and reducing vendor lock-in.", "body_md": "# Introduction\n\nLinkedRecords - A Backend-as-a-Service for collaborative SaaS applications\n\n- What if writing a production-ready SaaS application is\n[as easy as a React.js hello world tutorial](/getting-started/)? - What if you operate a SaaS on your infrastructure and your users could choose where their data lives - on their own infrastructure, in their own jurisdiction?\n- What if AI coding assistants couldn't accidentally create security holes because authorization is baked into every operation?\n- What if multiple apps could work with the same data without any integration work?\n\nLinkedRecords makes all of this possible. It's not just another BaaS - it's a fundamentally different architecture for building collaborative applications.\n\n[LinkedRecords](#linkedrecords)\n\nLinkedRecords is a Backend-as-a-Service that you can connect to directly from your single-page application - no backend code required. Think of it as a database you can call directly from your React app, with authorization built in and real-time collaboration out of the box.\n\nYou can use any OpenID Connect provider (Auth0, Keycloak, etc.) for authentication, so you don't need to implement login flows. Authorization is built into the data model itself - when you create data, you specify who can access it. And real-time collaboration uses CRDT and Operational Transform, so concurrent edits merge instead of overwriting each other.\n\n[Not Local-First, But Server-Sovereign](#not-local-first-but-server-sovereign)\n\nIf you've heard of **local-first** tools like Automerge, Yjs, or Replicache - LinkedRecords is different. The key distinction is where data lives and who enforces authorization.\n\n| Aspect | Local-First | LinkedRecords |\n|---|---|---|\nData lives | On the client | On the server |\nWorks offline | Yes | No |\nAuthorization | Client-side or sync-layer | Server-enforced |\n\n**Choose local-first** when users need to work offline or instant local response is critical.\n\n**Choose LinkedRecords** when you need server-enforced authorization, central governance over data, the BYOB model where customers control their backend, or audit trails that require server-side logging.\n\nThe difference is conceptual: local-first optimizes for offline capability, while LinkedRecords optimizes for a server-authoritative state with built-in authorization - making it well suited for enterprise SaaS.\n\n[Cloud Sovereignty](#cloud-sovereignty)\n\nTraditional SaaS has a problem: **the vendor controls your data**.\n\nWhen you use a typical SaaS application, the vendor operates the complete stack - the frontend, the backend, and the database where your data lives. Your business data sits on infrastructure you don't control, in a jurisdiction you might not have chosen.\n\nLinkedRecords enables a different model: **Bring Your Own Backend (BYOB)**.\n\n**How it works:**\n\n- SaaS vendors build their application as a single-page application\n- The frontend is distributed via CDN - just static files\n- When users open the application, the app can ask the user which LinkedRecords backend to use\n- All data is stored on the endpoint the user chose - data never leaves the customer's infrastructure\n- The SaaS vendor and the LinkedRecords provider never need to communicate - the API is intentionally minimalistic, providing just a few primitives (facts and attributes) that applications build upon. This minimal surface area is also the foundation for backwards compatibility: different versions of a SaaS application can work with different versions of LinkedRecords without coordination\n\n**Why this matters:**\n\n**Data residency compliance**- Keep data in your jurisdiction (GDPR, industry regulations)** No vendor lock-in**- Your data is in a database you control** Enterprise adoption**- Sensitive data stays on-premises** True ownership**- You can export, backup, and migrate freely** Still get SaaS benefits**- The application is still managed, hosted, and updated by the vendor. You get new features, bug fixes, and improvements automatically - only the data storage is under your control\n\n[Built for AI-Assisted Development](#built-for-ai-assisted-development)\n\nAs AI coding assistants become standard development tools, the architecture of your backend determines how safely and effectively these tools can work with it.\n\n[Authorization That's Harder to Misconfigure](#authorization-thats-harder-to-misconfigure)\n\nTraditional BaaS platforms separate authorization from data operations:\n\nLinkedRecords embeds authorization directly in data operations:\n\n**The secure default is automatic.** If you don't specify permissions, only you (the creator) can access the data. There's no separate rules file to forget about.\n\nThis means:\n\n- No forgetting to add rules for new collections\n- No accidental overly-permissive policies\n- No drift between code and authorization configuration\n- Security is co-located with the code that creates data\n\n[RDF-Inspired Facts: Natural for LLMs](#rdf-inspired-facts-natural-for-llms)\n\nThe triplestore pattern uses `(subject, predicate, object)`\n\n- the same structure as natural language sentences:\n\n| Natural Language | LinkedRecords Fact |\n|---|---|\n| \"Alice is a member of Engineering\" | `[alice, '$isMemberOf', engineering]` |\n| \"The document belongs to Project X\" | `[document, 'belongsTo', projectX]` |\n| \"Marketing can read the report\" | `[marketing, '$canRead', report]` |\n| \"Bob is accountable for this file\" | `[bob, '$isAccountableFor', file]` |\n\nThis semantic structure has potential benefits for AI-assisted development:\n\n**Readable**: LLMs may understand and generate correct facts more reliably** Flexible vocabulary**: Use any predicate for your domain (`belongsTo`\n\n,`assignedTo`\n\n,`partOf`\n\n) - only`$`\n\n-prefixed predicates are reserved for authorization**Predictable authorization**: The limited set of`$`\n\npredicates (`$canRead`\n\n,`$canAccess`\n\n,`$isMemberOf`\n\n, etc.) reduces the surface area for security errors**Self-documenting**: Relationships are visible in the code, not hidden in configuration** Verifiable**: An AI can reason about who has access by reading the facts\n\nWhen an AI assistant works with LinkedRecords, it can understand and verify permissions directly from the code - no need to cross-reference separate rule files.\n\n[Simpler Codebase, Fewer Tokens](#simpler-codebase-fewer-tokens)\n\nWith LinkedRecords, your entire application is frontend code. No backend routes, no database queries, no sync logic, no state management boilerplate. You create facts, create attributes, query attributes - everything is reactive and declarative.\n\nThis matters for AI agents:\n\n**Less code to understand**- Agents read fewer files and consume fewer tokens to grasp your application** Locality of behavior**- Authorization, data creation, and business logic live in one place. No jumping between frontend and backend codebases to understand what's happening**No hidden complexity**- There's no separate backend where authorization rules, API endpoints, or database schemas might contradict what the frontend expects\n\nTraditional full-stack applications split logic across frontend components, API routes, database models, and authorization config files. An AI agent must read and correlate all of these to make safe changes. With LinkedRecords, the relevant code is co-located - what you see is what you get.\n\n*Note: While the alignment between triple-based facts and natural language structure suggests advantages for LLM comprehension, this remains a hypothesis based on the semantic similarities. Real-world validation through broader adoption and systematic evaluation will determine the actual impact on AI-assisted development workflows.*\n\n[Real-Time Collaboration That Actually Works](#real-time-collaboration-that-actually-works)\n\nMost BaaS platforms offer \"real-time sync\" - but they use last-write-wins conflict resolution. When two users edit the same data simultaneously, one person's changes are silently overwritten.\n\nLinkedRecords provides **true collaborative editing**:\n\n| Data Type | Algorithm | What It Means |\n|---|---|---|\n| KeyValue (JSON) | CRDT | Concurrent edits to different fields merge automatically |\n| LongText | Operational Transform | Character-by-character collaboration like Google Docs |\n| Blob | Versioned | Binary files maintain version history |\n\nThis enables building applications like:\n\n- Collaborative document editors (Notion, Google Docs)\n- Real-time whiteboards (Miro, Figma)\n- Multiplayer productivity tools\n- Any application where users work together on shared data\n\n[No More Data Fetching Boilerplate](#no-more-data-fetching-boilerplate)\n\nBuilding a collaborative React application traditionally requires significant infrastructure:\n\n**What you need to build yourself:**\n\n- Backend API with CRUD endpoints\n- Database schema and queries\n- WebSocket server for real-time updates\n- Client-side state management (Redux, Zustand, React Query, etc.)\n- Cache invalidation logic\n- Optimistic updates with rollback\n- Conflict resolution when users edit simultaneously\n- Multi-tab synchronization via BroadcastChannel or storage events\n- Authentication and authorization middleware\n\n**With LinkedRecords, you skip all of that.**\n\nThe `useKeyValueAttributes`\n\nhook handles everything:\n\n**Queries by facts**- Declaratively specify what data you need** Persistence**- Data is stored on the LinkedRecords backend** Real-time sync**- Changes from any user appear instantly** Multi-tab sync**- All browser tabs stay consistent** Conflict resolution**- Concurrent edits merge automatically (CRDT)\n\nTo create or modify data:\n\n**No backend to build. No API endpoints. No state management library. No WebSocket code.**\n\nYour React components simply declare what data they need using facts. LinkedRecords handles persistence, synchronization, real-time updates, and multi-user collaboration.\n\n[Users Control Their Own Sharing](#users-control-their-own-sharing)\n\nIn most systems, a developer defines universal rules that apply to all users. In LinkedRecords, **users define who can access their own data**.\n\nThis model:\n\n- Puts users in control of their own data\n- Eliminates the need for complex centralized rule systems\n- Scales naturally - each user manages their own sharing\n- Matches how people think about sharing (\"I'll share this with you\")\n\n[Data Belongs to Teams, Not Applications](#data-belongs-to-teams-not-applications)\n\nIn traditional architectures, data is siloed by application. Your project management app has its own database. Your document editor has another. Your calendar has a third. Even if they're all about the same project and the same team, the data doesn't connect.\n\nLinkedRecords flips this model: **data is scoped to teams, not applications**.\n\n**What this enables:**\n\nMultiple applications can connect to the same LinkedRecords instance and work with the same data:\n\n**Reusable components across applications:**\n\nSince data follows a consistent pattern (facts and attributes), you can build components that work in any application:\n\n**Why this matters:**\n\n**No more data duplication**- Create your profile once, use it everywhere** Applications become views**- Different apps are just different ways to interact with your data** True interoperability**- Apps from different vendors can work together on shared data** User agency**- You choose which apps can access your data, and switch apps without losing anything** Composable software**- Mix and match specialized apps instead of using monolithic suites\n\nThis is a fundamentally different way of thinking about applications. Instead of each app being a walled garden with its own data, apps become lenses through which you view and manipulate your data. The data is yours, stored on your LinkedRecords instance, accessible to whatever tools you choose to use.\n\n**Ready to try it?** [Get Started](/getting-started/)", "url": "https://wpnews.pro/news/show-hn-write-saas-apps-where-users-control-where-their-data-is-stored", "canonical_source": "https://linkedrecords.com/", "published_at": "2026-06-16 10:53:00+00:00", "updated_at": "2026-06-16 11:19:19.043438+00:00", "lang": "en", "topics": ["ai-products", "developer-tools"], "entities": ["LinkedRecords", "Auth0", "Keycloak", "Automerge", "Yjs", "Replicache"], "alternates": {"html": "https://wpnews.pro/news/show-hn-write-saas-apps-where-users-control-where-their-data-is-stored", "markdown": "https://wpnews.pro/news/show-hn-write-saas-apps-where-users-control-where-their-data-is-stored.md", "text": "https://wpnews.pro/news/show-hn-write-saas-apps-where-users-control-where-their-data-is-stored.txt", "jsonld": "https://wpnews.pro/news/show-hn-write-saas-apps-where-users-control-where-their-data-is-stored.jsonld"}}