Talking about dark modes, nytimes still doesn't have an official dark mode (or not I can easily see). This should help.
They have it in the app… grrr
Forcing an inversion of control on the SaaS stack
21–30 of 50 posts
Re: Forcing an inversion of control on the SaaS stack
#22Earlier quoted context omitted.
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.
> 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.
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.
Re: Forcing an inversion of control on the SaaS stack
#23You don't want to ship every feature every user wants, for various reasons that I assume are obvious. Instead make it extensible.
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
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.
Re: Forcing an inversion of control on the SaaS stack
#24Earlier quoted context omitted.
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
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.
hence the sharability and subscription. other users need to explicitly subscribe to the page boosters. Else they continue with what they have.
Re: Forcing an inversion of control on the SaaS stack
#25I 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.
> have everyone believe that trivial feature requests take time to implement.
This could not be more wrong. Features do, because telling a user they can do X comes with a standing promise that it works, the results are correct, the ui is accessible, the feature cleanly interacts with all other features in the system (both now and in the future), corner cases are worked out, etc. And that burden is where prod+eng spend time.
Re: Forcing an inversion of control on the SaaS stack
#26I 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…
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.
the url for your company in your profile is misspelled.
Re: Forcing an inversion of control on the SaaS stack
#27Earlier quoted context omitted.
> 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.
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 workflows while still relying on the foundational work our platform does.
Re: Forcing an inversion of control on the SaaS stack
#28I 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.
Doesn’t sound like you have much experience in software businesses.
Re: Forcing an inversion of control on the SaaS stack
#29Although 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 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.
Re: Forcing an inversion of control on the SaaS stack
#30Earlier quoted context omitted.
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.
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.