alt Hacker NewsI hope there's some forced migration of the SaaS business model towards primarily being "just an API" for whatever magic sauce it is they have. Too much of SaaS moats are just locking the backend behind an undocumented API.
Users should be able to have full control over their experience interacting with third parties if they want it. This isn't unique to post-LLM stacks like this, but it seems like this shifts the balance of power.
The next step after injecting custom UI controls is to build completely alternative frontends. The next step after that should be to build generic local frontends that abstract over multiple comparable thirdparty providers.
Replies
Nice vision, "alternative frontends" is something really useful for horizontal SaaS. We do this for over 2000 customers, from field workers to CEOs of public companies, and it's so satisfying to hear the great feedback when they tell me that they finally have software perfectly adapted to their workflows.
I think the right step would be to somehow communicate to the vendor that this feature is needed (eliminating the PM backlog BS) and their coding Agents should pick it and build it. The real moat they have is SaaS vendors have everyone believe that trivial feature requests take time to implement.
So, it's just changing the problem up a level.
First, is a 500 because you are using the API in a way that is unexpected a customer found defect? If Claude can't find the answer, what is the expectation of support?
If an internal team makes a change that breaks your workflow (because it was an unexpected use case), is that a CFD?
Do teams slow down in new features because the API must be the stress test of a public api?
I'm fine with unsupported frontends but an external API will be very difficult to keep static.