Earlier quoted context omitted.
That is a very good observation. see a comment below: > One interesting open question now is: It is easy to say how the backend provider would bill the company for its services. It is harder for the app provider (the SPA) to bill their services.
Maybe this aligns with the current direction we are moving with AI. The frontend app itself becomes more and more worthless and in the future every frontend is custom made. linkedrecords makes this very possible especially if you combine it with some form of upper ontologies where apps can collaborate on the same data. Maybe it is not as big of a problem as pirating the app would be against the companies SLA and seri…
Show HN: Write SaaS apps where users control where their data is stored
21–30 of 36 posts
Re: Show HN: Write SaaS apps where users control where their data is stored
#22Re: Show HN: Write SaaS apps where users control where their data is stored
#23Earlier quoted context omitted.
Yeah, you definitely should have linked to that instead of a Github repo (or copied the text across to the repo readme). The copy is still pretty focused on the Developer experience building something that uses your thing. But I can't imagine anybody choosing to use this for a product until they know for sure that the end-user experience is painless and frictionless. I'm actually in the market for something like this…
the login flow is quite straight forward and much of the expirience depends on the OpenID connect provider the backend is trusting. You can go to https://monsterwriter.com/ and see the system in action. When you click on login you will be redirected to a login provider, which in case of MonsterWriter is auth0. But it could also be an open source (e.g. KeyCloak) or any other commercial OIDC provider. Then it is up to…
Reading the Getting Started code, it only shows me configuring storage as a developer. Nothing about users doing any sort of bring-your-own storage, let alone firing one up from scratch with a friendly workflow.
What am I missing?
Re: Show HN: Write SaaS apps where users control where their data is stored
#24Earlier quoted context omitted.
the login flow is quite straight forward and much of the expirience depends on the OpenID connect provider the backend is trusting. You can go to https://monsterwriter.com/ and see the system in action. When you click on login you will be redirected to a login provider, which in case of MonsterWriter is auth0. But it could also be an open source (e.g. KeyCloak) or any other commercial OIDC provider. Then it is up to…
I tried your monsterwriter site (nice looking app, by the way), and logged in with google. I don't see any option to "control where my data is stored". As far as I can tell as an end user, I've just created an account on your site. Reading the Getting Started code, it only shows me configuring storage as a developer. Nothing about users doing any sort of bring-your-own storage, let alone firing one up from scratch wi…
The initial idea for linkedrecords was: I never want to write backend code and I want to build real time collaboration app. The realization that this way the user can choose its own backend came later. The idea never made it into MonsterWriter. But it would be very simple to add.
So the current implementation of MonsterWriter just hard codes the linkedrecords backend instead of prompting the user to pick one.
Re: Show HN: Write SaaS apps where users control where their data is stored
#25Earlier quoted context omitted.
Maybe this aligns with the current direction we are moving with AI. The frontend app itself becomes more and more worthless and in the future every frontend is custom made. linkedrecords makes this very possible especially if you combine it with some form of upper ontologies where apps can collaborate on the same data. Maybe it is not as big of a problem as pirating the app would be against the companies SLA and seri…
... You could also sell a desktop app instead of a SaaS app. And then the desktop app connects to linkedrecords server. This model a few advantages: - You can do the purchasing in the app (.e.g traditional license keys) - The user is not affected if your business closes. He still has the desktop app running locally and can use any linkedrecords server.
Re: Show HN: Write SaaS apps where users control where their data is stored
#26Re: Show HN: Write SaaS apps where users control where their data is stored
#27Have you looked at the W3C's SOLID standard? I haven't looked deeply into what you're doing, but it sounds like a less interoperable version of what SOLID already does. https://solidproject.org/TR/protocol
Here is a small piece of text regarding this I've pulled from my notes:
Both the Solid project and LR share a foundational vision: decoupling data storage from software vendors and enabling interoperability across applications. In both approaches, data is stored in a vendor-independent backend.
However, the two systems differ in their focus and technical priorities. Solid is primarily concerned with personal data sovereignty. It empowers individual users to host their own “data pods” and control access on a per-resource basis using access control lists. In contrast, the LR architecture is tailored to enterprise-level SaaS scenarios, where data collaboration across roles and teams is essential. It supports fine-grained, logic-based access control policies embedded directly in a triplestore backend, enabling rich authorization scenarios without requiring domain-specific backend logic.
Solid prioritizes decentralized identity and personal agency, aiming to let users choose where their data is hosted and who can access it—typically across diverse web applications. LR, on the other hand, assumes a centralized or semi-centralized backend under customer control (e.g., an organization’s IT department or a trusted third party), while still preserving vendor independence.
LR provides a flexible API that enables single-page applications (SPAs) to dynamically query all resources a user has access to, based on the authorization logic encoded in the triplestore. In contrast, the Solid project addresses this challenge through the use of typed indexes—explicit data records maintained by each application to list identifiers (URLs) of resources relevant to the user. While this mechanism enables some level of resource discovery, it introduces overhead: applications must create, update, and sync these index records manually. This approach becomes particularly cumbersome in multi-user scenarios where different users have access to different subsets of resources.
Re: Show HN: Write SaaS apps where users control where their data is stored
#28This is especially interesting for API products. The tricky part is not just where user data lives, but where logs, traces, backups, and billing metadata live too.
Re: Show HN: Write SaaS apps where users control where their data is stored
#29Earlier quoted context omitted.
I tried your monsterwriter site (nice looking app, by the way), and logged in with google. I don't see any option to "control where my data is stored". As far as I can tell as an end user, I've just created an account on your site. Reading the Getting Started code, it only shows me configuring storage as a developer. Nothing about users doing any sort of bring-your-own storage, let alone firing one up from scratch wi…
You don't miss anything. The initial idea for linkedrecords was: I never want to write backend code and I want to build real time collaboration app. The realization that this way the user can choose its own backend came later. The idea never made it into MonsterWriter. But it would be very simple to add. So the current implementation of MonsterWriter just hard codes the linkedrecords backend instead of prompting the…
Why not use that space to say something that your thing actually does? It’d save everyone a lot of confusion.
Re: Show HN: Write SaaS apps where users control where their data is stored
#30I'm thinking to open source it but I want to see some traction before doing that since I don't want to open source then someone else takes my code and I get nothing out of it.