faaleoleo · June 2026 · Strategy
The software market is about to fragment in a way that the backup and disaster recovery industry is not prepared for. Today, a skilled backup team can protect most of what matters by mastering a manageable set of widely adopted platforms. That model is not going to hold. AI is changing not just how software is used — it is changing what software gets built, who builds it, and how long any given application stays in its current form. The implications for backup and DR are fundamental.
Walk into any enterprise today and you will find a predictable stack. A handful of dominant ERP systems. Two or three hypervisor platforms. A few major database engines. Cloud infrastructure concentrated in three providers. The backup industry built itself around this reality — deep integrations with the platforms that matter, connectors for the vendors with enough market share to justify the development investment, and APIs that the major players maintain because it is in their commercial interest to do so.
This concentration made backup manageable. A team that understands the major platforms, knows the integration points, and keeps their tooling current can protect the overwhelming majority of production workloads. It is still demanding work, but it is bounded work. The number of things to know is large but finite.
That world is changing.
AI is not primarily a productivity tool bolted onto existing software. It is a force that is lowering the cost of building custom software to the point where building custom becomes the rational choice for an expanding set of problems.
Today, organisations adopt standardised platforms and then spend years adapting their processes to fit the platform. That trade-off — flexibility for maintainability — made sense when building something custom required a large team, long timelines, and ongoing engineering investment. Those constraints are loosening rapidly.
When AI development tooling matures to the point where a domain expert can describe what they need and a small team can build a production-grade application in weeks, the economics shift. Why adapt your workflow to an off-the-shelf product when a custom solution that fits your exact process is now within reach? Why pay for a platform that includes ninety features you will never use when you can build the ten you need?
The result is a market moving from concentration toward fragmentation. Not overnight — but directionally, and with growing momentum.
A backup team operating in a fragmented software market faces a qualitatively different problem than the one they face today.
The number of distinct applications in any given environment will grow. Many of them will be custom-built with no established backup connector, no vendor-maintained API, no support forum with answers to the specific integration question that matters right now. Some will be built by teams that have moved on. Some will have been written to solve a problem so specific that it exists in only one organisation in the world.
The team still has to back them up. The regulatory obligation does not become less demanding because the software is novel. NIS2 requires backup procedures and tested recovery capability regardless of whether the application is SAP or a custom AI-driven workflow tool used by four people in a specific department. The NIST frameworks do not carve out exceptions for bespoke software. The business continuity expectation from the board does not flex to accommodate "we do not have an integration for that one."
What changes is the nature of the work. Standard integrations — the pre-built connectors and agent-based backups that cover the dominant platforms — will not reach these applications. Protecting them will require the ability to understand what they are, how their data is structured, where their state lives, and what a valid recovery actually looks like. Then it requires building something that works, on a timeline that keeps pace with how quickly the application itself may change.
That is a different kind of capability.
Backup infrastructure was largely designed for a world of stable, well-documented platforms. The dominant approach — install the agent, configure the job, run the backup — works because the platform's vendor has done the work of making it work. The agent knows where the application's data lives. The documentation covers the edge cases. The integration has been tested against every version the vendor has released.
Custom software does not come with that. There is no agent. The developer who understood the data model may no longer be available. The application may have changed significantly since it was first deployed, and the backup configuration that worked a year ago may now be incomplete in ways that are not visible until recovery is attempted.
This problem scales with fragmentation. A team managing ten well-supported standard applications can maintain confidence in their backup posture through a regular testing regime. A team managing ten standard applications and forty custom or niche ones faces a different equation — the forty are the ones most likely to fail at recovery, the least likely to have been tested, and the most likely to have changed without the backup team being informed.
Protecting a fragmented software landscape requires flexibility at every level of the backup operation.
At the integration layer, the ability to build custom backup workflows for applications that have no standard connector. This means scriptable, programmable backup infrastructure — not a product that can only do what the vendor has pre-built.
At the discovery layer, the ability to understand what is running in an environment, identify what is new, and assess what a backup of each component actually needs to cover. In a stable environment this is a one-time exercise. In a dynamic environment where new custom applications appear regularly, it has to be ongoing.
At the testing layer, the ability to verify recovery at a frequency that matches the rate of change. An application that is actively being developed may change its data structure significantly in a month. A recovery test that passed in January does not confirm recovery capability in April.
At the operational layer, the ability to maintain a clear picture across a large and heterogeneous set of protected workloads — without that operational view becoming itself a full-time job.
One thing that will not change as the software market fragments is the compliance landscape. NIS2 names backup management explicitly as a legal requirement for organisations in scope. The NIST Cybersecurity Framework's recover function requires documented backup procedures and tested recovery capability. These obligations apply to every production system — not only the ones where a vendor has made backup easy.
This creates a specific risk in the coming environment: the gap between what a compliance report says is protected and what is actually recoverable will widen, silently, as the number of custom and niche applications grows faster than the team's capacity to maintain integrations for them.
A compliance programme built for a concentrated software landscape will not remain compliant as that landscape fragments — unless the backup capability that supports it can keep pace.
faaleoleo is being built with this fragmentation trend as a design constraint, not an afterthought.
The backend is Bacula Enterprise — not because it is the most familiar platform, but because it is the most programmable. Bacula's architecture supports the kind of custom integration work that protecting non-standard applications requires. When a client is running a custom application with no established connector, the tools exist to build what is needed rather than accepting a gap in protection.
The faaleoleo assistant, which is in active development and will ship as part of the service, is designed specifically for the operational challenge of a heterogeneous and dynamic environment. Understanding what is running, identifying what changed, assessing what a backup is actually covering, and surfacing problems before they become recovery failures — these are the tasks that scale badly when done manually, and the tasks the assistant is being built to handle.
The combination addresses both sides of the fragmentation challenge: a backend capable of being adapted to protect whatever the environment contains, and an operational layer that can maintain the required visibility without the overhead growing in proportion to the number of protected workloads.
The fragmentation of the software market is a directional trend, not a discrete event with a start date. Most organisations are not yet managing forty custom AI-driven applications — but most organisations are also not standing still. The number of custom tools, departmental applications, and AI-assisted workflows is growing in almost every environment we work with, and it is growing faster than backup coverage is being extended to meet it.
The question worth asking now is not whether this challenge will arrive — it is whether the backup infrastructure in place is capable of meeting it when it does. The organisations that will navigate this transition well are the ones that recognised the trajectory early enough to invest in flexible, programmable backup infrastructure before the gap between what they are running and what they are protecting became a compliance or recovery problem.
We are building faaleoleo to be the backup and DR partner for organisations operating in a dynamic, fragmented software landscape — not only the ones where standard integrations cover everything. The tools to do this are not all shipped yet. The assistant is in development. But the architecture is designed for this environment, the backend can support it, and the direction is clear.
If you are responsible for backup and DR in an environment where the software landscape is changing faster than the standard tooling can keep up, we would like to talk about what that looks like in practice.
Reach us at contact@faaleoleo.io.