6 ms·

Forcing an inversion of control on the SaaS stack

81 points by shardullavekar 5mo ago

bobbiechen 5mo ago
Enterprise userscripts? Very neat, though I wonder if typical enterprise security policies would allow for this.
- namanyayg 5mo ago
  One way to solve it is to partner with the enterprise directly and work within their guardrails Shameless plug: my company does it, live with Series B companies.
- shardullavekar 5mo ago
  got our extension approved, post which we had no issues.
- hrimfaxi 5mo ago
  Unless the browser locks down devtools you can't you always run userscripts to some extent?
treyd 5mo ago
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.
- namanyayg 5mo ago
  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.
  - apsurd 5mo ago
    the url for your company in your profile is misspelled.
    - namanyayg 5mo ago
      Ty fixed! Allow me to blame it on the lack of sleep as I'm in the current yc batch.
      - apsurd 5mo ago
        Good luck! The premise sticks immediately. If attention-span was shot with social-media, it has no chance in the age of AI. All these deep tech-tools potentially have tons of value, but if it doesn't make sense in 5 seconds, very hard to compete.
- shardullavekar 5mo ago
  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.
  - treyd 5mo ago
    That introduces a level of indirection between "what I want" and what gets built. A workflow like the OP just has less friction. SaaS platforms would want to provide more stable accessible APIs if it becomes a popular model, because users would find it more usable.
    - shardullavekar 5mo ago
      these embeddable UI could be a direct ask on how users want a workflow, the SaaS vendors can distribute the embeddable UI and see if it clicks with a lot of users. Would push them to create a stable API
  - drewbeck 5mo ago
    > The real moat they have is SaaS vendors have everyone believe that trivial feature requests take time to implement. So true. People are going to be sooo mad when they find out we all have these Build Features For Free buttons and just don't press them.
    - apsurd 5mo ago
      Surprised this is your take coming from a UX designer. You think a straight path for every user to add their feature ideas results in a good UX? edit: reading further into this, the idea is perhaps that users vibe-code their own distinct UX with everything valuable to them. That's not a bad take, but even in that world, I wouldn't think UX and product disciplines become exposed for having no value at all.
      - drewbeck 5mo ago
- ebiester 5mo ago
  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.
  - raw_anon_1111 5mo ago
    The last company I worked for before going into consulting full time was a startup where I was the then new CTOs first technical hire. The company before then outsourced the actual technical work to a third party consulting company until they found product market fit. His primary mandate was API and micro service first. Our customers were large health care systems. We had a customer facing website that was built on top of the same APIs that we sold our customers. Our customers paid for the features they wanted and those features were available on our website, they were used for their website and mobile apps and the ETL process was either via a file they sent us and we ran through the same APIs or they could use our APIs directly for both online and batch processes. This is no different from the API mandate Bezos made at Amazon back in 2000. You don’t have to keep an API static - that’s what versioning is for.
    - apsurd 5mo ago
      I think the talking point is maintaining a well versioned and solid API as product is way harder than shipping a few screens that can change whenever you need them to. (behind those screens being a bunch of duct tape to a clusterF of internal APIs). no guarantees. what you're saying is that you were at a company that did that hard thing of shipping APIs as product.
namanyayg 5mo ago
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) Exciting times!
- mpeg 5mo ago
  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 the line? I've seen fat finger errors cause financial loss, but at least in those cases the user always had a chance to realise their error and fix it, with something like this how would you even know?
  - namanyayg 5mo ago
    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.
    - chrisweekly 5mo ago
      your profile's blog link 404s
      - namanyayg 5mo ago
        Fixed https://nmn.gl/blog https://nmn.gl/blog
mads_quist 5mo ago
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.
- shardullavekar 5mo ago
  > In the end, your obligation as a company, regardless of your product, is to generate profits. No denying that. SaaS started with a user problem at the center of it and as they scaled, forgot about an individual user. This only presents the user frustration and a possible solution to it.
  - drewbeck 5mo ago
    > as they scaled, forgot about an individual user If you're building for individual users you're not going to succeed. We all prioritize for broad success from the beginning. I'm very into the idea of inversion of control and giving users this flexibility but I agree with GP that the SaaS company critique is misplaced. I hope you find enough success with 100X that you end up coming to the same conclusion. I'll also add that one of your video examples is essentially a Twitter spam generator; is that the kind of feature you think SaaS companies should be prioritizing?
    - shardullavekar 5mo ago
      I created that twitter responder after reading this post (https://news.ycombinator.com/item?id=47568028 https://news.ycombinator.com/item?id=47568028). That wasn't to call out what SaaS companies should prioratise but to show how easy it would be for a user to do it.
- pixl97 5mo ago
  >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 legally mandated companies be evil. It's been working out well for us in the US as prices skyrocket and any competition is bought up or abused with patents/IP.
codegladiator 5mo ago
how far it can go ? complete page rewrites ?
esafak 5mo ago
You don't want to ship every feature every user wants, for various reasons that I assume are obvious. Instead make it extensible.
- shardullavekar 5mo ago
  users didnt ask for slow apis either but there they are. I am speaking for the user here and sharing their frustration. Allowing UI modification to fit the user needs should be a default now. The APIs already act as a gaurdrail on what's possible
  - esafak 5mo ago
    Configurability in moderation is fine, but go too far and users can hurt each other. JIRA is famous for this: managers customize the life out of it at others' expense.
    - shardullavekar 5mo ago
      hence the sharability and subscription. other users need to explicitly subscribe to the page boosters. Else they continue with what they have.
mrjn 5mo ago
Talking about dark modes, nytimes still doesn't have an official dark mode (or not I can easily see). This should help.
- xixixao 5mo ago
  They have it in the app… grrr
socketcluster 5mo ago
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/ https://saasufy.com/
ksaxena 5mo ago
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?
- hephaes7us 5mo ago
  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.
qwertyuiop_ 5mo ago
* system of records, SOC2, security perimeters, handling concurrency) are real. Migration of data is painful too.* This is not a moat.
bjornroberg 5mo ago
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.
amelie0 5mo ago
[flagged]

Enterprise userscripts? Very neat, though I wonder if typical enterprise security policies would allow for this.

namanyayg 5mo ago
One way to solve it is to partner with the enterprise directly and work within their guardrails Shameless plug: my company does it, live with Series B companies.
shardullavekar 5mo ago
got our extension approved, post which we had no issues.
hrimfaxi 5mo ago
Unless the browser locks down devtools you can't you always run userscripts to some extent?

treyd 5mo ago

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.

namanyayg 5mo ago
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.
- apsurd 5mo ago
  the url for your company in your profile is misspelled.
  - namanyayg 5mo ago
    Ty fixed! Allow me to blame it on the lack of sleep as I'm in the current yc batch.
    - apsurd 5mo ago
      Good luck! The premise sticks immediately. If attention-span was shot with social-media, it has no chance in the age of AI. All these deep tech-tools potentially have tons of value, but if it doesn't make sense in 5 seconds, very hard to compete.
shardullavekar 5mo ago
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.
- treyd 5mo ago
  That introduces a level of indirection between "what I want" and what gets built. A workflow like the OP just has less friction. SaaS platforms would want to provide more stable accessible APIs if it becomes a popular model, because users would find it more usable.
  - shardullavekar 5mo ago
    these embeddable UI could be a direct ask on how users want a workflow, the SaaS vendors can distribute the embeddable UI and see if it clicks with a lot of users. Would push them to create a stable API
- drewbeck 5mo ago
  > The real moat they have is SaaS vendors have everyone believe that trivial feature requests take time to implement. So true. People are going to be sooo mad when they find out we all have these Build Features For Free buttons and just don't press them.
  - apsurd 5mo ago
    Surprised this is your take coming from a UX designer. You think a straight path for every user to add their feature ideas results in a good UX? edit: reading further into this, the idea is perhaps that users vibe-code their own distinct UX with everything valuable to them. That's not a bad take, but even in that world, I wouldn't think UX and product disciplines become exposed for having no value at all.
    - drewbeck 5mo ago
ebiester 5mo ago
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.
- raw_anon_1111 5mo ago
  The last company I worked for before going into consulting full time was a startup where I was the then new CTOs first technical hire. The company before then outsourced the actual technical work to a third party consulting company until they found product market fit. His primary mandate was API and micro service first. Our customers were large health care systems. We had a customer facing website that was built on top of the same APIs that we sold our customers. Our customers paid for the features they wanted and those features were available on our website, they were used for their website and mobile apps and the ETL process was either via a file they sent us and we ran through the same APIs or they could use our APIs directly for both online and batch processes. This is no different from the API mandate Bezos made at Amazon back in 2000. You don’t have to keep an API static - that’s what versioning is for.
  - apsurd 5mo ago
    I think the talking point is maintaining a well versioned and solid API as product is way harder than shipping a few screens that can change whenever you need them to. (behind those screens being a bunch of duct tape to a clusterF of internal APIs). no guarantees. what you're saying is that you were at a company that did that hard thing of shipping APIs as product.

namanyayg 5mo ago

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) Exciting times!

mpeg 5mo ago
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 the line? I've seen fat finger errors cause financial loss, but at least in those cases the user always had a chance to realise their error and fix it, with something like this how would you even know?
- namanyayg 5mo ago
  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.
  - chrisweekly 5mo ago
    your profile's blog link 404s
    - namanyayg 5mo ago
      Fixed https://nmn.gl/blog https://nmn.gl/blog

mads_quist 5mo ago

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.

shardullavekar 5mo ago
> In the end, your obligation as a company, regardless of your product, is to generate profits. No denying that. SaaS started with a user problem at the center of it and as they scaled, forgot about an individual user. This only presents the user frustration and a possible solution to it.
- drewbeck 5mo ago
  > as they scaled, forgot about an individual user If you're building for individual users you're not going to succeed. We all prioritize for broad success from the beginning. I'm very into the idea of inversion of control and giving users this flexibility but I agree with GP that the SaaS company critique is misplaced. I hope you find enough success with 100X that you end up coming to the same conclusion. I'll also add that one of your video examples is essentially a Twitter spam generator; is that the kind of feature you think SaaS companies should be prioritizing?
  - shardullavekar 5mo ago
    I created that twitter responder after reading this post (https://news.ycombinator.com/item?id=47568028 https://news.ycombinator.com/item?id=47568028). That wasn't to call out what SaaS companies should prioratise but to show how easy it would be for a user to do it.
pixl97 5mo ago
>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 legally mandated companies be evil. It's been working out well for us in the US as prices skyrocket and any competition is bought up or abused with patents/IP.

codegladiator 5mo ago

how far it can go ? complete page rewrites ?

esafak 5mo ago

You don't want to ship every feature every user wants, for various reasons that I assume are obvious. Instead make it extensible.

shardullavekar 5mo ago
users didnt ask for slow apis either but there they are. I am speaking for the user here and sharing their frustration. Allowing UI modification to fit the user needs should be a default now. The APIs already act as a gaurdrail on what's possible
- esafak 5mo ago
  Configurability in moderation is fine, but go too far and users can hurt each other. JIRA is famous for this: managers customize the life out of it at others' expense.
  - shardullavekar 5mo ago
    hence the sharability and subscription. other users need to explicitly subscribe to the page boosters. Else they continue with what they have.

mrjn 5mo ago

Talking about dark modes, nytimes still doesn't have an official dark mode (or not I can easily see). This should help.

xixixao 5mo ago
They have it in the app… grrr

socketcluster 5mo ago

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/ https://saasufy.com/

ksaxena 5mo ago

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?

hephaes7us 5mo ago
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.

qwertyuiop_ 5mo ago

* system of records, SOC2, security perimeters, handling concurrency) are real. Migration of data is painful too.* This is not a moat.

bjornroberg 5mo ago

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.

amelie0 5mo ago

[flagged]