Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Forcing an inversion of control on the SaaS stack

100x.bot

Post reply on HN
Print view View original

31–40 of 50 posts

Re: Forcing an inversion of control on the SaaS stack

#31

Post by apsurd »

drewbeck wrote: post #27
apsurd wrote: post #22

Earlier quoted context omitted.

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.

My take in this (ironic) comment was just "no feature is free", which I don't think should be odd coming from a UX designer! > the idea is perhaps that users vibe-code their own distinct UX with everything valuable to them I do find this interesting. I work on a complex business operations and reporting platform and every facility has their own lil quirks. More control in their hands would let them smooth out their w…

Ah, I didn't register the sarcasm. Typical HN, it's probably why you're downvoted.

Yes, today's HN session has me nerd-sniped about what the future of product development looks like. I've been thinking how mock-to-prototype is just too slow when engineers can ship so much so fast. Eng needs design direction especially when it's too easy to "solve design" with tailwind components and "You're a designer from a top saas company" prompts.

But what if the new UX is less visual-first and more IA, primitives and well structured object models... now that has me thinking.

Re: Forcing an inversion of control on the SaaS stack

#32

Post by apsurd »

namanyayg wrote: post #30
apsurd wrote: post #26

Earlier quoted context omitted.

the url for your company in your profile is misspelled.

Ty fixed! Allow me to blame it on the lack of sleep as I'm in the current yc batch.

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.

Re: Forcing an inversion of control on the SaaS stack

#33

Post by ebiester »

treyd wrote: post #3

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 ba…

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.

Re: Forcing an inversion of control on the SaaS stack

#34

Post by mpeg »

namanyayg wrote: post #4

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 featur…

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?

Re: Forcing an inversion of control on the SaaS stack

#35

Post by raw_anon_1111 »

ebiester wrote: post #33
treyd wrote: post #3

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 ba…

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 a…

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.

Re: Forcing an inversion of control on the SaaS stack

#36

Post by raw_anon_1111 »

shardullavekar wrote: post #8
treyd wrote: post #3

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 ba…

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.

There is an entire industry of Salesforce, Workday, ServiceNow consultants and almost any other major SaaS app that you can hire to customize the app based on public APIs. I can’t imagine choosing any mission critical SaaS app without publicly documented APIs

Re: Forcing an inversion of control on the SaaS stack

#37

Post by raw_anon_1111 »

mads_quist wrote: post #7

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.

The right answer is just to have a well documented publicly available API for your customers and eat your own dogfood.

Re: Forcing an inversion of control on the SaaS stack

#39

Post by namanyayg »

mpeg wrote: post #34
namanyayg wrote: post #4

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 featur…

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.

Re: Forcing an inversion of control on the SaaS stack

#40

Post by apsurd »

raw_anon_1111 wrote: post #35
ebiester wrote: post #33

Earlier quoted context omitted.

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 a…

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 t…

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.

Post reply on HN