From SaaS to Software as an AI Service
- Krzysztof Kosman
- May 14
- 7 min read
For years, software companies have sold a familiar promise: subscribe to the platform, configure it once, train your team, and let the product do the rest.
That model is not dead. But it is starting to bend.
In my conversation with Emil Elchanan Reisser-Weston, founder of Open eLMS, one idea stood out far beyond the EdTech category: AI is not just changing how software creates content. It is changing how software is configured, operated, extended, and even owned. In other words, the more interesting shift may not be from “manual work” to “automation,” but from software as a service to something closer to software as an AI service.
That framing matters because it moves the conversation away from the usual hype.
This is not about slapping a chatbot on top of a dashboard. It is about rethinking the relationship between the product, the vendor, and the client. It is about what happens when a complex system stops asking users to learn its internal logic and starts adapting itself, conversationally, to the user’s intent.
The real AI opportunity is not content generation
Much of the AI discussion in software still focuses on output: faster writing, faster prototyping, faster design, faster code.
That matters, but it is not the whole story.
What Emil described is more structural. Open eLMS is not a lightweight product with a handful of switches. It is a long-developed system with hundreds of features, role properties, reporting options, and implementation choices. His point was simple: once a platform becomes powerful enough, the real bottleneck is no longer whether it can do more. The bottleneck is whether anyone can realistically configure and use all that capability without drowning in complexity.
That is where AI becomes more than a feature.
In his words, the system now has an AI front end for reporting, form production, and configuration. Instead of forcing a client through months of setup logic, the product can ask what kind of business they run, what they need, what integrations matter, and what their operating context looks like. The user describes intent. The system translates that into setup.
That is a fundamentally different model of interaction.
Not: “Here is the admin panel, good luck.”
But: “Tell me what you are trying to achieve.”
Complex software has always had a translation problem
This is not only an LMS story.
Many mature B2B systems reach the same point eventually. Over time they accumulate features, settings, rules, exceptions, templates, permissions, and integrations. Each new enterprise customer adds another layer of edge cases. The system becomes more capable, but also harder to implement cleanly.
Traditionally, companies have solved this with consultants, onboarding teams, implementation specialists, custom support, documentation, and training. None of that is wrong. But it is expensive, slow, and hard to scale.
Emil described exactly that pressure. If a system has 680 features and hundreds of role-related properties, the problem is not only technical depth. The problem is translation. How does a user know what matters to them? How do they turn their business reality into a working setup without spending three months in configuration hell?
AI, in that context, acts as a translation layer.
It does not remove the complexity underneath. It mediates it.
That is one of the clearest practical uses of AI in enterprise software right now: not replacing the product, but making the product legible.
Effortless products are often the most engineered
One thing I liked in this conversation is that Emil did not romanticize simplicity.
He explicitly compared a well-designed system to Netflix: the experience feels intuitive and effortless, but only because an enormous amount is happening under the surface. The ease is not accidental. It is engineered.
That is an important correction to how many teams think about UX.
Simple interfaces are often treated as evidence of small scope. In reality, the opposite is often true. The best product experiences feel easy because the messy work has been absorbed inside the system rather than exported to the user.
AI expands the range of how that can be done.
A conversational layer, smart defaults, agent-driven recommendations, dynamic setup, contextual reporting, generated dashboards, or guided workflow creation all move in the same direction: they compress product complexity into a more natural interaction model.
This is where AI becomes strategically interesting.
Not because it produces text.Because it changes how complexity is presented.
SaaS assumed the vendor would keep doing the hard part
The classic SaaS model is clear: the vendor owns the platform, operates the infrastructure, ships the improvements, and the client pays for access.
That still works for a huge share of software.
But Emil’s view points toward something more fluid. He talked about a future in which clients do not only rent a platform. They increasingly modify it, extend it, and build on top of it. In his framing, the product starts to look less like a sealed service and more like a base system that clients can actively shape.
That is where his phrase becomes useful: software as an AI service.
The distinction is subtle but important. In software as a service, the value is primarily access. In software as an AI service, part of the value shifts toward enablement. The client is not only using the system. They are using the system, plus AI, plus the vendor’s architecture, to alter their own workflows with less dependence on the vendor for every small change.
That is a meaningful change in power distribution.
And it fits a broader trend we already see in low-code, no-code, internal tooling, and AI-assisted development: more organizations want products they can shape without filing a ticket every time reality changes.
Vibe coding is real, but structure still wins
This is where the conversation got more honest than most AI optimism pieces.
Emil clearly sees vibe coding becoming more mainstream. He thinks more people will build their own internal systems, automate more of their operational flows, and rely on AI to compress work that used to take hours into minutes. He gave a practical example from his own workflow: automating a video production process that previously required several tools and manual handoffs.
But he also gave the caveat that too many people skip.
Yes, AI-generated code is useful. Yes, it gets better. But no, that does not mean you can treat architecture, refactoring, maintenance, or business analysis as optional. He was very direct that vibe-coded systems break, models change, outputs drift, and enterprise-grade software still needs structure.
That tension is exactly where many product teams are right now.
AI lowers the barrier to creation.It does not lower the need for judgment.
In fact, it may raise it.
Because when software can be altered faster, bad decisions can also spread faster. Weak architecture becomes visible sooner. Temporary shortcuts turn into operational debt more quickly. A rough prototype can feel deceptively complete right before it collapses under real usage.
That is why one of the strongest lines in the interview was not even about technology. It was about roles. Emil said his programmers are increasingly being trained to think more like business analysts: to understand solutions, shape prompts, and reason through workflows before the code layer even begins.
That feels directionally right.
In an AI-heavy environment, the premium shifts upward from raw production toward framing, architecture, decomposition, and decision quality.
The future may be more service-heavy, not less
There is a lazy story that AI will turn software into pure self-service.
Maybe in some categories. But I do not think that is the full picture.
The more convincing version is what Emil suggested: products may become more extensible and more client-shaped, while vendors make more of their money through consultancy, architecture, implementation support, and platform expertise rather than through pure access alone. He even compared it to the music industry moving from albums to concerts: less value in the static artifact, more value in the surrounding service layer.
That is not a downgrade of software. It is a rebalancing.
If AI lowers the cost of producing many things inside the platform, then competitive advantage shifts toward:
who designs the best architecture
who provides the best implementation logic
who makes extension safest
who helps clients adapt faster
and who turns a platform into a durable operating model
That is a very different commercial posture from old SaaS.
And frankly, it is one many software firms should already be preparing for.
What EdTech teaches the rest of software
The reason this conversation matters beyond learning is that EdTech makes certain product tensions easier to see.
When a learning system is bad, people feel it quickly. It is too slow, too dull, too confusing, too generic, too disconnected from the moment of need. But the same underlying problems exist across many other product categories:
software that is too configurable for normal humans
systems that depend on expert intermediaries
dashboards that expose internals instead of outcomes
AI features that generate more, but simplify nothing
platforms that scale capability faster than they scale usability
That is why the Open eLMS example is interesting even if you do not care about LMS products at all.
It shows what happens when AI is treated less like a shiny front-end feature and more like an operational layer: a translator, a configurator, a workflow compressor, and eventually a bridge between the vendor’s platform and the client’s evolving needs.
The shift is not from software to AI. It is from static software to adaptive software.
That is the broader takeaway I would keep.
The next generation of products will not win just because they “have AI.” That bar is too low.
They will win if AI helps them do three things better than the old SaaS model:
reduce the cost of complexity
let clients adapt the system faster
move human effort toward higher-value decisions
If that happens, the product is no longer just a service you subscribe to.
It becomes a system that helps you reconfigure the service itself.
That is a much bigger shift than better content generation.
And it may be one of the clearest signs that the SaaS model, while still alive, is starting to evolve into something more dynamic, more collaborative, and more demanding of both vendors and clients.
Software as a service was about delivering the platform.
Software as an AI service may be about helping the platform keep changing after delivery.
