> For one thing, the threat model assumes customers can build their own tools.
That's not the threat model. The threat model is that they won't have to - at some point which may not be right now. End users want to get their work done, not learn UIs and new products. If they can get their analysis/reports based on excels which are already on SharePoint (or wherever), they'd want just that. You can already see this happening.
Yes. This is also why trying to add an AI agent chat into one's product is a fool's errand - the whole point of having general-purpose conversational AI is to turn the product into just another feature.
It's an ugly truth product owners never wanted to hear, and are now being forced to: nobody wants software products or services. No one really wants another Widgetify of DoodlyD.oo.io or another basic software tool packaged into bespoke UI and trying to make itself a command center of work in their entire domain. All those products and services are just standing between the user and the thing the user actually wants. The promise of AI agents for end-users is that of having a personal secretary, that deals with all the product UI/UX bullshit so the user doesn't have to, ultimately turning these products into tool calls.
I think that's just true in general. Business users at $work are already saying that they would rather just talk to ChatGPT (with voice for some reason I, a keyboard person, doesn't understand) than deal with GUIs. They want to describe what they need and have the computer do it, not click around.
Once you've abstracted away the UI (and the training on how to use it) it will be a lot easier to just swap one SaaS for another.
Yes, except for the fact that any non-trivial saas does non-trivial stuff that an agent will be able to call (as the 'secretary') while the user still has to pay the subscription to use.
Yes, but now it's easier for other SaaS to compete on that, because they don't get to bundle individual features under common webshit UI and restrict users to whatever flows the vendor supports. There will be pressure to provide more focused features, because their combining and UI chrome will be done by, or on the other side of, the AI agent.
Also, having to retrain users to use a new shitty UI after they got used to the previous shitty UI is a major moat of many SaaS services. The user doesn't care about the web portal, they just want to get work done. Switching to a different web portal needs to be a big net positive because users will correctly complain that now they are unproductive for a while because the quirks and bugs of the previous SaaS don't match those of the new SaaS.
In a world where the interface is "you talk to the computer" you will be able to swap providers way more easily.
That's the brilliance of AI - it doesn't matter if the product actually works or not. As long as it looks like it works and flatters the user enough, you get paid.
And if you build an AI interface to your product, you can make it not work in subtly the right ways that direct more money towards you. You can take advertising money to make the AI recommend certain products. You can make it give completely wrong answers to your competitors.
>> This is also why trying to add an AI agent chat into one's product is a fool's errand - the whole point of having general-purpose conversational AI is to turn the product into just another feature
We built an AI-powered chat interface as an alternative to a fully featured search UI for a product database and it has been one of the most popular features of 2025.
Sure, but it would be even better if it was accessible by ChatGPT[0] and not some bespoke chat interface you created - because with ChatGPT, the AI has all the other tools and can actually use yours in intelligent ways as part of doing something for the user.
> No one really wants another Widgetify of DoodlyD.oo.io
I keep hearing this and seeing people buying more Widgetify of DoodlyD.oo.io. I think this is more of a defensive sales tactic and cope for SaaS losing market share.
The president of a company I work with is a youngish guy who has no technical skills, but is resourceful. He wanted updated analytic dashboards, but there’s no dev capacity for that right now. So he decided he was going to try his hand at building his own dashboard using Lovable, which is one of these AI app making outfits. I sent him a copy of the dev database and a few markdown files with explanations regarding certain trickier elements of the data structure and told him to give them to the AI, it will know what they mean. No updates yet, but I have every confidence he’ll figure it out.
Think about all the cycles this will save. The CEO codes his own dashboards. The OP has a point.
I'd argue it's not CEOs job to code his own dashboards...
This sounds like a vibe coding side project. And I'm sorry, but whatever he builds will most likely become tech debt that has to be rewritten at some point.
Or to steel-man it, it could also end up as a prototype that forced the end user to deal with decision points, and can serve as a framework for a much more specific requirements discussion.
At a certain scale the CEO's time is likely better spent dictating the dashboard they want rather than implementing it themselves. But I guess to your point, the future may allow for the dictation to be the creation.
Agree, as engineers we should be making the car easier to operate instead of making everyone a mechanic.
Focus on the simple iteration loop of "why is it so hard to understand things about our product?" maybe you cant fix it all today but climb that hill more instead of make your CEO spend some sleepless nights on a thing that you could probably build in 1/10th the time.
If you want to be a successful startup saas sw eng then engaging with the current and common business cases and being able to predict the standard cache of problems they're going to want solved turns you from "a guy" to "the guy".
And I wonder if they will discover that in order to interpret those numbers in a lot of cases they will need to bring in their direct reports to contextualise them.
If corporate decisions could be made purely from the data recorded then you don't need people to make those decisions. The reason you often do is that a lot of the critical information for decision making is brought in to the meeting out-of-band in people's heads.
I have also seen multiple similar use cases where non-technical users build internal tools and dashboards on top of existing data for our users (I'm building UI Bakery). This approach might feel a bit risky for some developers, but it reduces the number of iterations non-technical users need with developers to achieve what they want.
Honestly, I'm not sure what to expect. There are clearly things he can't do (e.g. to make it work in prod, it needs to be in our environment, etc. etc.) but I wouldn't be at all surprised if he makes great headway. When he first asked me about it, I started typing out all the reasons it was a bad idea - and then I paused and thought, you know, I'm not here to put barriers in his path.
The Excel holy grail. Dashboard are an abstraction, SaaS is an abstraction of an abstraction from the pov of customers suffering from a one size fits all. Shell scripts generated by LLMs that send automated a customized reports via email will make a lot of corporate heros. No need to login, learn and use the SaaS in many instances for decisions makers.
I feel that large corps have guard rails that will limit this from happening. For SMB's, this is not a new problem. Gritty IT guys have been doing this for decades. I inherit these bootstrapped reporting systems all the time. The issue is when that person leaves, it is no longer maintainable. I've yet to come across a customer who has had any sort of usable documentation. The process then repeats itself when I take over, and presumably when I'm finished. With a SaaS product, you are at least paying for some support and visibility of the processes. I'm not really trying to make a point other than this is not a new, but still intriguing problem, and not sure that LLMs will be some god answer, as the organizations have trouble determining what they even need.
Yes, back in the heyday of Visual Basic (mid-1990s) we had one business analyst who learned enough to build dashboard-like apps with charts and graphs and parameters and filters. He was quick at it and because it was outside of IT there was little in the way of process or guardrails to slow him down. Users loved what he did, but when he left there was nobody else who knew anything about it.
That's not the threat model. The threat model is that they won't have to - at some point which may not be right now. End users want to get their work done, not learn UIs and new products. If they can get their analysis/reports based on excels which are already on SharePoint (or wherever), they'd want just that. You can already see this happening.