I 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.
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.
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.
Nice post and I agree that making software with really simple UX for last mile cases is the solution to the SaaS-pocalypse and is something new that was not possible before AI.
I'm solving this from the other side of the equation: we work directly with the SaaS vendors to make vibe coding embedded into their platform. Working with some Series B companies right now, 2000 business users are now able to build any feature they want, within the guardrails of the SaaS vendor. (More info in profile if anyone wants to chat)
Although I absolutely understand the frustration expressed by the author, I find the notion that SaaS companies are somehow 'evil' because they optimize for the 80/20 rule a bit arrogant. Anyone working in SaaS - or really in any business- understands that you need to prioritize. In the end, your obligation as a company, regardless of your product, is to generate profits. And that's absolutely OK.
SaaS needs to be reinvented. We need backend platforms which provide more security controls, more flexibility in terms of data-sharing, seamless access by AI agents with advanced access controls; e.g. some agents can define schemas, some agents read data, other agents write data, some agents curate data... And custom app frontends can be generated on demand and integrate data from many different sources. This is what I've been working towards with https://saasufy.com/
Solves yesterday's problem. The calcification is UI calcification, and agents don't care about UIs. An MCP server (or a half-decent OpenAPI surface) lets a user-controlled agent compose vendor primitives without touching the DOM, without TOS risk, without overlay maintenance. IoC doesn't get forced by extensions. It gets forced by agents that can read docs and click buttons faster than the vendor can ship features. The vendors who notice will expose that surface voluntarily, because the alternative is getting scraped anyway.
This bothers me. ALL enterprise SaaS prohibits reverse-engineering in its TOS and CSA and most prohibit bots and automation. So, the buyer will need the vendor's explicit permission to use something like 100x; and when the vendor has something on the roadmap, even if it's delayed, there's little chance that the vendor will give this permission. Anybody else bothered by this? Anybody who has a successful workaround?
47 comments
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.
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.
I'm solving this from the other side of the equation: we work directly with the SaaS vendors to make vibe coding embedded into their platform. Working with some Series B companies right now, 2000 business users are now able to build any feature they want, within the guardrails of the SaaS vendor. (More info in profile if anyone wants to chat)
Exciting times!
This is not a moat.