4 ms·

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 Saa

by treyd 6mo 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 6mo 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 6mo ago
  the url for your company in your profile is misspelled.
  - namanyayg 6mo ago
    Ty fixed! Allow me to blame it on the lack of sleep as I'm in the current yc batch.
    - apsurd 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo ago
ebiester 6mo 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 6mo 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 6mo 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.

by treyd 6mo ago

namanyayg 6mo 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 6mo ago
the url for your company in your profile is misspelled.
- namanyayg 6mo ago
  Ty fixed! Allow me to blame it on the lack of sleep as I'm in the current yc batch.
  - apsurd 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo ago

ebiester 6mo 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 6mo 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 6mo 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.