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?
Forcing an inversion of control on the SaaS stack
41–50 of 50 posts
Re: Forcing an inversion of control on the SaaS stack
#42* system of records, SOC2, security perimeters, handling concurrency) are real. Migration of data is painful too.*
This is not a moat.
Re: Forcing an inversion of control on the SaaS stack
#43Earlier quoted context omitted.
I don't have a horse in this race, but this seems the right way to me. As a developer, I do already inject custom scripts to provide extra functionality / automation on SaaS I use where APIs are not available or limited. However, the thought of the non-technical users I work with doing that is scary, they have no idea if the code the LLM writes is correct, is it going to have a bug that causes a massive issue down th…
I'm glad to hear that it resonates! And yes, being able to provide a guardrailed environment has been the biggest problem that we're solving. Now every customer can get the power of Claude Code and vibe coding in a safe and controlled environment.
your profile's blog link 404s
Re: Forcing an inversion of control on the SaaS stack
#44Earlier quoted context omitted.
I'm glad to hear that it resonates! And yes, being able to provide a guardrailed environment has been the biggest problem that we're solving. Now every customer can get the power of Claude Code and vibe coding in a safe and controlled environment.
your profile's blog link 404s
Fixed https://nmn.gl/blog
Re: Forcing an inversion of control on the SaaS stack
#45Solves 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.
Re: Forcing an inversion of control on the SaaS stack
#46This 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?
This is essentially a smarter auto-clicker. I'm not sure I'd call it "reverse engineering".
A TOS/CSA should in no way ever attempt to prohibit automation, and if it does, it (generally) deserves to be disrespected.
There is a legitimate concern however about customer resource use escalating beyond what was expected when the price was set. Luckily this can be written as a simple black and white determination without any complicated gray areas, and is therefore easily enforced both in the code and in the contract.
Re: Forcing an inversion of control on the SaaS stack
#47Re: Forcing an inversion of control on the SaaS stack
#48Although 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.
>In the end, your obligation as a company, regardless of your product, is to generate profits. Moloch demands babies be scarified to generate maximum profits! For one, this is a very US concentric way of thinking. Secondly, if a human person thought like this we'd consider them to be an anti-social psychopath, which directly conflicts with the more recent SCOTUS ruling that companies are humans too. So, yes, we have…
[dead]
Re: Forcing an inversion of control on the SaaS stack
#49Earlier quoted context omitted.
Fixed https://nmn.gl/blog
Right on. (Smart take on SaaS, too, BTW)
ty! any CEOs or product people at SaaS companies that come to mind to reach out to? I've been trying to get this in front of more people, so far they're always mind blown when they see how the product works
Re: Forcing an inversion of control on the SaaS stack
#50[flagged]