AI
The Future of SaaS Is Cloneable
For a long time, AI-coded software has had an obvious ceiling.
You could vibe code a demo polished enough to post to Twitter, like a dashboard, content editor, CRM, or half-working internal tool.
Then, you tried to use it. Daily.
Things would break. You'd try to fix them with the AI, but the second pass made it worse than before. The data model was wrong. The UI got fragile. The agent couldn't really tell which parts mattered, and what looked like a product turned out to be mostly a screenshot.
Thing is, that's starting to change.
Better coding agents, app patterns, and ways to connect agents to real interfaces and data are making some internal apps useful enough to keep improving and use day to day.
It's definitely not for every enterprise workflow, and not every compliance-heavy system where reliability, support, and procurement matter more than customization. But for personal software, technical teams, and internal workflows, the line is moving.
AI is making it practical to own, customize, and connect the everyday software your team actually uses. SaaS isn't dead yet, but the moat is shrinking.
Internal tools suddenly got real
Let's look at a real-life example of this.
Teams are buried in data: product events, sales records, support tickets, call notes, billing systems, or a warehouse only three people really understand.
The usual SaaS answer is analytics software, which definitely helps, but the moment your exact dashboard doesn't exist, you're kinda screwed. You file a request, export a CSV, ask a data person, or settle for the closest chart.
So, what if you had a tool that worked out-of-the-box, but that you could own and customize the second you needed it to be different?
That's what we've been doing at my company with our own internal analytics app. Multiple teams are already using it for real work: sales can look for stalled accounts, support can inspect ticket patterns, product can ask where users drop off, and GTM can build event prep views from several systems.
The analytics team still owns the core tool. They define data sources, shared concepts, metrics, and dashboard patterns. And the app still has a UI, saved dashboards, and structure people can understand.
But when an exact view doesn't exist, anyone can ask the app's agent to just... make it. The agent can query any of our data sources, figure out which ones it needs to create the charts, and save a new dashboard that everyone can now use. It can actively adapt the app around how our team works.
The app stays stable where stability matters. The agent flexes where the workflow needs flexibility.
That's different than your traditional chatbot bolted onto SaaS. It's more like having a portable Claude Code with a fully dynamic UI. It's a different relationship between the user, the app, the data, and the agent.
We've been calling it agent-native apps.
The old SaaS way of doing things is dying
SaaS usually wins because building polished software is really, really hard.
The bargain goes something like this. SaaS companies absorb the work most teams don't want to own: hosting, auth, databases, permissions, integrations, support, reliability, design, and a thousand other product decisions that actually make software usable.
In return, teams pay for the tool. Buying beats building because the alternative is becoming a software company for every little workflow.
SaaS also encodes product learning. Calendar apps, mail clients, and docs apps aren't just tables, simple wrappers, or naked text areas. SaaS companies spent years discovering the primitives that actually make these categories of software feel good to use.
But in order to figure all that out, SaaS has always had to operate at scale. And so the bargain has a cost: the software is generalized.
It has features you don't need, lacks the exact feature you want, integrates (but not deeply enough), and offers AI only in that vendor's chosen shape. This isn't a failure of SaaS so much as just the nature of the generalized software beast.
A mail client has to work for sales, support, founders, recruiters, executives, writers, and even folks who just learned that a double click doesn't mean pressing both mouse buttons. Analytics has to satisfy teams asking vastly different questions.
And that's a tradeoff we all accepted, because building your own version was obviously too expensive. But SaaS has already taught us the useful primitives of each category. If AI makes it easy to clone those primitives without inheriting the vendor's one-size-fits-all assumptions, then the math changes.
It's no longer a question of only, "Which SaaS tool should we buy?" It's also, "Which workflows are specific enough to us that owning and customizing the tool would give us significant gains?"
Cloning SaaS workflows doesn't mean making slop forks
There is an obvious bad version of this future: the slop fork.
In the slop fork version, AI copies the surface area of a product without understanding the constraints that make it work. It copies the UI, routes, database shape, and demo interactions, but when you actually try to use it, it feels... overloaded. It's hard to parse what anything does or means. It's not built from first principles.
That's because software isn't a visible feature list. Mature products are packed with invisible judgment: defaults, permissions, sync behavior, recovery flows, keyboard behavior, data models, and edge cases that only look obvious after years of use.
Asking AI to implement a SaaS clone shouldn't be, "Hey, reverse engineer this for me." Instead, you need to understand the stable primitives of the workflow you need and then customize from there.
Templates can really help with this, and lately my team has been open sourcing a bunch of the most helpful bits of our internal tools, to help folks get started. They're free to use. You just need an AI subscription to something like Cl
A good template should be generic. It's just there to capture the basic shape of the category that SaaS has been defining for decades. For instance:
- Mail needs inboxes, threads, accounts, and fast triage.
- Content needs documents, editors, comments, and sharing.
- Analytics needs queries, dashboards, charts, saved views, and metric context.
- Forms need questions, responses, branching, and exports.
Once those primitives are captured in a cloneable template, you can focus on what you want to customize about that stable base instead of reinventing the wheel. Let the agent add custom actions, data integrations, dashboards, automations, shortcuts, and workflow-specific UI.
That's the difference between slop forks and useful clones. Slop copies everything badly. Useful clones start with the basics and only add what you need. They become yours over time.
Agents + UI is way more powerful
A basic cloned app is useful. An agent-native cloned app is where things get way more exciting.
The old AI pattern was to bolt a chatbot onto an existing product. It could answer questions, summarize, draft, or trigger a few narrow actions, but it didn't really share the UI's context or operate the same workflows a human could.
Agent-native apps start from a different premise: the agent and the UI are one system.
The UI gives us humans (👋) a structured surface to work in: dashboards, timelines, tables, documents, canvases, inboxes, and forms. The agent gets access to the app's actions, state, and context, so it can see what changed, understand what object is selected, and choose the operation that would actually help.
The UI gives the workflow a repeatable shape. The agent gives that shape flexibility.
A cloneable mail client is useful. A cloneable mail client with an agent that understands your inbox, CRM context, calendar, team, and preferred workflows is a different kind of tool.
The same pattern applies to content, analytics, clips, slides, forms, calendars, video editors—whatever. Once the agent is native to the app, even a basic interface becomes a way to expand what the model can do.
For instance, I'm writing this article in an agent-native content tool (Notion clone), where I can press one button to publish to our blog when I'm done, and the app will report back to me on the article's success or failure. Wildly helpful stuff.
Owned data makes the app smarter
Customization isn't even the biggest advantage of owned, team-specific software. The biggest advantage is all the context you can give the app and agent.
Generic SaaS knows only the data it is allowed to know. Your own app can start from the data the workflow actually needs.
An email client can see the relationship, deal status, and likely need behind a message. Our analytics app can build an event-prep view by pulling together account data, call context, and internal notes that normally live in separate systems.
The content workspace I'm writing in can understand the publishing pipeline, brand constraints, SEO research, articles, and performance data. Internal linking stops being a scavenger hunt; the tool shows me, in one place, every article linked from a draft, then suggest related pages by conversion signal.
This is where generalized SaaS starts to feel strange. If your team has the data, and AI can turn it into interfaces and automations, why trap every workflow inside a vendor's product assumptions?
A2A makes apps a network
Traditional SaaS integrations depend on vendor incentives. Companies aren't always motivated to make products work deeply with competitors, and even good integrations reflect the vendor's flows.
A2A gives agent-native apps another path: apps can talk directly across team workflows. If I have an analytics question while writing content, I can just ask from the content workspace. Slides can turn Gong calls into a pitch deck. Mail can ask Calendar for availability.
Suddenly, the simple primitives feel more like legos. Your individual cloned apps become a software graph.
If you own the apps, protocols, and data flow, you don't have to negotiate between vendors for the integrations you need. It's just part of the architecture.
Where enterprise SaaS still makes sense
This isn't an argument that every company should replace every SaaS product with AI-coded internal tools. Stability, compliance, support, procurement, security, permissioning, trust, and long-term maintenance all still matter.
But agent-native apps don't need to beat enterprise SaaS everywhere. They just need to be specific, owned, and stable enough for personal workflows, internal tools, and technical-team workflows.
That stability gap isn't gone yet, but it's closing fast with this latest generation of AI coding tools. And the customization gap is already enormous. When the rented tool is stable but misfit, and the cloned tool is stable enough but shaped around the work, more teams will choose the tool that fits.
Make software that fits you better
The future of SaaS isn't that every product disappears. It's that more software becomes something you can own, reshape, and connect—especially as more folks make better and better open source templates.
We've been working on that here with our agent-native cloneable templates for the categories teams already rent: mail, calendar, content, slides, video, analytics, clips, design, forms, a Dispatch control plane, and a minimal Starter scaffold. They map to familiar Superhuman, Gmail, Calendar, Notion, Docs, Pitch, Looker, Loom, Figma, Canva, and Typeform-style workflows.
So, pick a workflow that's been annoying you lately, or a tool you're tired of paying for. Clone the closest template, try it with real work, connect the data that matters, and ask the agent to shape the app around how you actually operate.
If it helps, keep shaping it. If it breaks, open an issue. If you improve it, send a PR.
And if the idea clicks, feel free to star the repo, join the Discord, and help define what agent-native software should become.
With any luck, the next generation of software won't be a thousand subscriptions we juggle. It'll be tools we clone, customize, and make fit.
Share
