For decades, software applications have followed a familiar architecture.
A company builds a frontend, develops the backend, stores the user's data, and sells access to the entire package through a subscription or advertising.
Whether you're using a task manager, calendar, email client, or financial application, you're generally buying into an integrated ecosystem. The interface, business logic, and data are bundled together.
But what happens when users no longer need those interfaces?
As AI assistants become increasingly capable of interacting with software on our behalf, I believe we're approaching a significant shift in application architecture.
Many applications will no longer need to build and maintain their own dedicated frontends. Instead, they can focus on providing reliable, inexpensive data services that users access through whichever AI assistant or application they prefer.
Not every application will follow this model. Specialized interfaces will remain essential for many use cases.
But for a substantial portion of today's software industry, AI could fundamentally change what an application is—and what users are actually paying for.
The Three Layers of AI-Native Applications
I envision the next generation of applications increasingly separating into three layers:
- Frontend (Harness): The interface through which users interact with software, whether that's a general-purpose AI assistant or a specialized application.
- AI Model Providers: The intelligence that understands user intent, reasons through problems, and performs tasks.
- Data and Services (MCP/APIs): The systems responsible for storing information, retrieving data, and executing operations.
These layers already exist, but they're often bundled together by the same provider.
My prediction is that they'll become increasingly independent.
Users will be able to choose their preferred interfaces, AI models, and data providers without necessarily committing to a single ecosystem.
This separation has the potential to create entirely new markets—and put significant competitive pressure on existing software companies.
1. The Frontend: AI Becomes the Primary Interface, But Not the Only One
One of the more ambitious predictions about AI is that we'll eventually interact with virtually everything through a single assistant.
I think there's some truth to that.
It's incredibly convenient to have one AI assistant that knows your preferences, maintains context across conversations, and can interact with the various services you use.
Imagine starting your day by asking:
"What's on my calendar, what tasks need my attention, and is there anything important I should know?"
Your assistant could retrieve information from several independent services, organize it, and present the results without requiring you to open a single traditional application.
For many everyday activities, that conversational interface may be all you need.
But there's an important limitation.
One company can't build the best interface for everything
Consider CAD software, mapping applications, video editors, financial charting tools, and spreadsheets.
These applications have sophisticated interfaces developed around highly specialized workflows.
A conversational interface might be excellent at understanding what you want to accomplish, but that doesn't necessarily make it the best way to interact with the results.
You might ask an AI to design a mechanical component, but you'll probably still want a 3D modeling interface to inspect and refine the design.
You might ask an AI to plan a road trip, but an interactive map is still a better way to visualize the route.
And while AI can generate or analyze spreadsheets, there are plenty of situations where viewing and manipulating a grid of information remains valuable.
It's unrealistic to expect a single AI company to build and maintain the best possible interface for every conceivable use case.
The good news is that it doesn't have to.
Many of those specialized interfaces already exist.
Rather than being replaced, I expect these applications to become increasingly AI-enabled, allowing users to communicate intent through natural language while retaining the specialized visual tools that make them useful.
The distinction: Data-centric versus interface-centric applications
This leads to an important distinction.
Some applications derive much of their value from managing information.
Others derive substantial value from the specialized interface they provide.
A task manager is a good example of the former.
Most task management operations are relatively straightforward: create a task, assign a due date, organize projects, update priorities, and mark work as completed.
An AI assistant can perform these operations without requiring a dedicated task management interface.
CAD software, on the other hand, requires complex visual interaction. Even with increasingly capable AI, there's significant value in retaining a specialized environment for manipulating detailed designs.
Of course, this isn't a strict division. Many applications fall somewhere between these extremes.
But I suspect data-centric applications will be among the first to experience significant disruption.
The opportunity for specialized AI frontends
I don't think general-purpose AI assistants will be the only successful interfaces.
Developers will also create specialized AI-powered frontends tailored to particular industries, workflows, and user experiences.
Some will be new applications. Others will be existing applications that evolve to incorporate AI.
The important difference is that these frontends won't necessarily need to provide their own models or data infrastructure.
They can focus on delivering the best user experience for a particular purpose.
And increasingly, users may be able to bring their own intelligence.
2. The AI Model Layer: Bring Your Own AI
Today, most people interact with AI through applications provided by the organizations developing the models.
ChatGPT, Claude, and other assistants combine the interface, intelligence, and subscription into a relatively integrated experience.
That's convenient, but it creates a form of lock-in.
If you prefer a particular model, you're often incentivized to use the interface provided by its developer.
I think this relationship will gradually change.
BYOAI: Bring Your Own AI
Imagine being able to connect your preferred AI model provider to any compatible application.
You might use one model for software development, another for research, and a locally hosted model for private information.
The frontend would provide the experience and tools, while the chosen AI model supplies the intelligence.
I'm calling this BYOAI: Bring Your Own AI.
This could allow specialized software developers to build sophisticated AI-powered experiences without developing or operating their own large language models.
It would also give users substantially more flexibility.
If a new model offers better performance or pricing, they could switch without replacing their entire application ecosystem.
The catalyst: AI subscription and API pricing converge
There's an important economic obstacle to this vision.
Many AI providers currently offer subscriptions with relatively generous usage allowances for a predictable monthly price.
Accessing those same models through APIs can be significantly more expensive, particularly for heavy users.
That gives customers a powerful reason to remain inside the model provider's native application.
But imagine a future where users can access their preferred models through third-party applications at economics comparable to their existing subscriptions.
Whether that happens through portable subscription entitlements, prepaid usage, or more competitive API pricing, the result would be similar.
Users could select their preferred frontend without sacrificing the pricing benefits of their preferred model.
I believe this shift could be a major catalyst for the unbundling of AI applications.
It isn't guaranteed. Model providers benefit from owning the user experience and customer relationship, and they may resist changes that weaken those advantages.
But competitive pressure could eventually make broader interoperability increasingly attractive.
Intelligence could become a commodity
The cost of developing frontier AI models remains extraordinarily high, placing this layer largely beyond the reach of most independent developers.
However, smaller and specialized models continue to improve.
Over time, more applications may be able to use inexpensive models or run capable models locally.
If sufficiently powerful models become economical on commodity hardware, some applications may not require external AI providers at all.
In those cases, the intelligence layer could effectively become part of the frontend.
The long-term opportunity for model providers will be to offer better intelligence at increasingly competitive prices.
3. The Data Layer: Where the Biggest SaaS Disruption Could Happen
Of the three layers, I believe the data layer presents one of the most interesting opportunities.
Think about how many applications we currently pay for primarily to manage information.
Task managers, calendars, note-taking applications, document storage, email, simple CRM systems, and countless other tools.
These applications typically bundle three things:
- A user interface.
- Business logic and operations.
- Data storage and retrieval.
But if AI assistants increasingly provide the interface, why should every data service need to build and maintain one?
This is where I think the economics of software could change dramatically.
Consider a task management application
Take Todoist as an example.
Today, a task management company needs to build and maintain web applications, mobile applications, desktop applications, and the infrastructure that supports them.
It needs developers, designers, testing infrastructure, and ongoing maintenance for those experiences.
Now imagine a competing service that provides only task storage, synchronization, and a reliable API.
Users manage their tasks entirely through their preferred AI assistant.
They can create tasks, organize projects, update deadlines, and retrieve information without ever opening a dedicated task management application.
That backend-only provider has no need to develop a sophisticated frontend.
Its business becomes storing and managing task information as efficiently and reliably as possible.
Without the cost of maintaining an entire suite of user interfaces, it could potentially offer the same underlying functionality at a significantly lower price.
The total cost to users would still depend on AI inference and other service costs. But the backend-only provider could have a meaningful structural cost advantage.
And that creates competitive pressure.
Traditional SaaS companies would be competing not only against other full-featured applications but also against much leaner data-service providers.
MCP and APIs become the interface
The Model Context Protocol, or MCP, provides one possible mechanism for connecting AI applications to these independent services.
Rather than developing custom integrations for every AI frontend, backend providers could expose standardized tools and resources that compatible assistants can discover and use.
MCP doesn't replace databases, backend logic, or traditional APIs.
It provides a standardized way for AI applications to interact with those capabilities.
In this model, backend developers can focus on what they do best: reliable data storage, efficient operations, security, scalability, and interoperability.
Instead of competing primarily on frontend features, they can compete on the quality and cost of the underlying service.
Frontend developers compete on experience. Model developers compete on intelligence. Backend developers compete on reliability, functionality, and price.
The Real Benefit: Your Data Is No Longer Tied to Your Interface
There's another benefit to separating these layers that may be just as important as lower costs.
Portability.
Today, switching applications often means exporting data, importing it elsewhere, learning a new interface, and potentially losing functionality or historical information.
In the architecture I'm describing, the data provider and frontend can be independent.
You could manage your tasks through ChatGPT today, Claude tomorrow, and a specialized productivity application next week.
All three could interact with the same task management backend.
Your data stays where it is.
The same principle could apply to calendars, documents, notes, and other information.
Your primary AI assistant might remain the center of your digital experience, maintaining context and coordinating activities across services.
But you wouldn't be forced to use that assistant forever.
You could switch AI providers or specialized interfaces without migrating your underlying information.
That's a meaningful shift in control from application providers toward users.
Of course, genuine portability requires more than exposing an API. Providers must support interoperable data models, authentication, permissions, and sufficiently complete operations.
But the architectural separation makes this flexibility possible.
4. The Business Model: Software Becomes a Utility
If applications increasingly separate their frontends from their backends, there's an opportunity to rethink how we pay for software.
Today, many software companies rely on flat monthly subscriptions.
You might pay for a task manager, note-taking application, calendar service, cloud storage, and multiple content subscriptions, even if you use some of them infrequently.
But if these services operate primarily as independent data providers, usage-based pricing becomes more practical.
Storage can be billed by capacity.
Operations can be billed by request.
Premium data can be charged according to consumption.
Rather than paying a fixed monthly fee for an entire application, users could increasingly pay for the underlying resources they actually consume.
This doesn't mean subscriptions disappear.
Heavy users may prefer predictable monthly plans, and some services will continue to bundle functionality.
But competition from lower-cost backend-only providers could put downward pressure on prices across many software categories.
Cryptocurrency could enable micropayments
One challenge with usage-based pricing is efficiently charging for very small transactions.
Traditional payment infrastructure isn't always economically practical for individual payments worth fractions of a dollar.
Cryptocurrency-based payment systems, particularly stablecoins on low-cost networks, could help address this problem.
Imagine your AI assistant having access to a wallet with a user-defined spending limit.
When it needs information from a third-party provider, it could automatically purchase access without requiring a separate subscription.
This would enable machine-to-machine commerce, where software services purchase resources directly from other software services.
Cryptocurrency isn't the only potential solution. Traditional payment providers could develop similarly efficient infrastructure.
But programmable payments could become an important component of this new application economy.
5. Example: News Becomes an On-Demand Data Service
Consider how people access premium news today.
If you're researching a particular company, you might want information from The Wall Street Journal, MarketWatch, and several other publishers.
But accessing that information may require maintaining separate subscriptions, even if you only want a few articles.
Imagine instead that publishers offered individual articles or access to their content through paid APIs.
Your AI assistant could identify relevant sources, determine the cost, and purchase the information on your behalf.
You could specify a budget, such as:
"Research this company using reputable financial publications. You can spend up to $2 accessing premium sources."
The AI would retrieve the necessary information through the participating providers, potentially using MCP to access their services and programmable payments to purchase content.
Publishers would get paid for the information consumed.
Users would get access to the information they need without maintaining numerous subscriptions.
For occasional readers, this could be substantially more economical.
Such a system would require publishers to support this business model, along with mechanisms for rights management, authorization, and payment settlement.
But technically and economically, it's an interesting direction for content distribution.
6. What Happens to Existing Software Companies?
I don't expect existing SaaS companies to simply disappear.
Many have substantial advantages beyond their user interfaces.
They operate mature infrastructure, maintain valuable integrations, understand complex business workflows, and have established customer relationships.
Some will continue offering vertically integrated applications because their customers value the complete experience.
Others may increasingly expose their backend functionality to third-party AI frontends.
And some may eventually find that their greatest competitive advantage lies in providing reliable data services rather than maintaining a proprietary interface.
The most vulnerable companies could be those whose products primarily provide relatively simple operations around structured information.
If an AI assistant can replicate most of the user experience by connecting to an inexpensive backend, maintaining an expensive, full-featured frontend becomes harder to justify.
Meanwhile, companies providing sophisticated visual workflows may face less pressure to eliminate their interfaces.
Instead, they'll increasingly integrate AI into the experiences they already provide.
This won't happen everywhere
There are practical reasons to keep some systems tightly integrated.
Performance-sensitive software, applications requiring sophisticated local interactions, and systems with complex real-time requirements may benefit from tightly coupling their frontend and backend.
Security, compliance, and reliability requirements may also favor integrated architectures.
Unbundling shouldn't become an architectural requirement imposed on every application.
The opportunity is to separate these responsibilities where doing so improves flexibility, economics, or the user experience.
7. What This Means for Software Developers
I see significant opportunities for developers throughout this transition.
Frontend developers can focus on building highly specialized interfaces and experiences. They won't necessarily need to create their own AI models or maintain proprietary data infrastructure.
Backend developers can build independent services that provide storage, operations, integrations, and access to valuable information. Their competitive advantage will come from reliability, performance, interoperability, and cost efficiency.
AI model developers can concentrate on improving intelligence, expanding capabilities, and reducing inference costs.
And independent software developers could find it increasingly practical to assemble sophisticated applications from these services without owning the entire technology stack.
In some cases, entirely new software businesses may consist of little more than an efficient backend and a standardized interface for AI agents.
That's a substantially different business model from the traditional SaaS application.
The Biggest Obstacles
There are several reasons this transition may be slower than the technology itself would allow.
First, many incumbent software companies have strong financial incentives to preserve their integrated ecosystems.
Controlling the frontend, backend, and customer relationship creates lock-in and makes it easier to capture revenue across the entire stack.
Second, the economics of AI usage still favor certain bundled offerings.
As long as users receive substantially better pricing through a model provider's own application, independent frontends face a disadvantage.
Third, standardized interoperability is still evolving.
MCP provides a useful foundation, but developers also need dependable authentication, authorization, billing, data portability, security, and service-level guarantees.
Finally, consumers and businesses may simply prefer integrated solutions when the convenience outweighs the potential cost savings.
These challenges are significant.
But I believe competition will increasingly reward companies that make their services accessible through multiple interfaces and AI providers.
The Future Is Unbundled
I don't believe the future of software is one AI assistant replacing every application.
There's too much value in specialized interfaces for that to happen universally.
Instead, I envision a world where most people have a primary AI assistant that handles their everyday digital interactions.
When they need a specialized interface, they can open one without abandoning their AI context or moving their underlying data.
Behind those experiences, independent model providers supply intelligence, while data providers compete to deliver reliable, inexpensive services.
Users can switch frontends, change AI models, and choose where their information lives.
Developers can focus on the layers where they create the most value.
And many of the software services we currently purchase as expensive, vertically integrated subscriptions could evolve into much leaner, usage-based utilities.
The biggest disruption from AI may not be that it replaces software applications. It may be that it makes large portions of the software we're currently paying for unnecessary.