There’s clearly a lot happening in the SaaS and AI space, more questions than answers at this point.
One thing becoming clear to me: the traditional SaaS web app, led by the page- and form-based browser UI, needs to be reconsidered. The UI’s role in a SaaS application (say, a CRM) must be decoupled from the business logic and data model. Architecturally it might already be, but it’s not licensed that way.
The reason is straightforward: ChatGPT-style conversational interfaces have become (or are rapidly becoming) the norm. Expectations for enterprise applications will follow. It may not be exclusively chat-based, but likely chat-first, with forms and lists served up when needed. A sales rep could start by asking to log a client activity or pipeline opportunity conversationally, then be presented with a form or list as required, rather than starting with multiple forms and fields.
SaaS vendors are facing their incumbent’s dilemma moment. It’s a matter of time before startups build AI-first enterprise apps—or existing ones deliver enterprise-grade solutions.
Just as SaaS upended on-prem delivery, conversational AI will loosen the grip of the browser UI as the primary data and reporting entry point.
We’re already seeing major CRM vendors launch conversational add-ons, but often as premium tiers bolted onto existing licence structures. This means paying for a browser UI your users may barely touch, plus another licence for the conversational AI they actually use. (And the consumption vs. per-seat licensing debate remains unsettled, adding yet more planning and budgeting complexity.)
Instead, it’s time to liberate the UI from the database. What’s needed: industry-specific data models with a choice of UI integration options (conversational, traditional, or hybrid) mediated by business logic and governance layers. Let customers choose the interface that fits their users and workflows, without being locked into a monolithic licence that bundles everything together.
(I haven’t addressed agentic AI driving autonomous workflows here. For my money, it’s too early to implement outside of experimentation, the purpose of which would be to understand the tech and its wider impacts on data quality tolerances, process reconfiguration, and skill development. The received wisdom from the (small) sample of actual deployments: data, processes, and skills must be “fixed” first. No mean feat.)