This week, Gartner predicted that, by 2029, 80% of new applications will be deliberately disposable, designed to be used for less than a year. AI-assisted development, it argues, will make it cheap and easy enough for employees to create applications around temporary business needs rather than waiting for those needs to be absorbed into the permanent technology estate.
At first glance, this sounds like another chapter in the citizen-development story. More people can build software, so organisations will have more software to manage. But the more interesting part of the prediction is not who builds the application. It is that nobody expects to stick around.
If an application can be created for a particular project, customer, problem or moment, used for six months and then dismantled, software starts to behave less like infrastructure and more like a temporary team, spreadsheet or working document: assembled around an outcome and discarded when its usefulness ends.
What changes when organisations can continuously generate temporary digital structures around the work?
Software has always carried the economics of permanence
Software has historically been expensive to create and expensive to change. Even relatively modest applications need requirements gathering, design, development, testing, integration, security review, deployment, training and support. Enterprise platforms amplify that investment further.
When something takes eighteen months and a significant budget to introduce, longevity becomes part of its economic justification. You don’t build it for the next nine months; you build it for the foreseeable future.
A temporary requirement appears and, rather than creating technology precisely fitted to it, people adapt themselves to the systems already available. A project team creates another spreadsheet. A function adds fields to an existing platform. Someone builds a dashboard. People develop manual workarounds between systems designed for slightly different purposes. The technology remains relatively fixed while the people bend around it.
Imagine a nine-month product launch involving people from product, marketing, sales, legal and operations. Instead of adapting several permanent systems to accommodate this temporary configuration of work, the team creates a small application specifically for the launch.
It knows the relevant project context, connects to authorised enterprise data, coordinates workflows and brings together the agents and tools the team needs. Its interface reflects the decisions this particular group is making.
When the launch ends, the records worth retaining flow back into the organisation’s permanent systems. The application itself disappears. It isn’t just the software that has become cheaper, but the cost of creating a specific, tailored, temporary structure around the work has fallen.
You can already see the edges of this
Look around most organisations today and you can see the beginnings of this shift, even if nobody is calling it disposable software yet.
A team creates an AI assistant to coordinate a project.
Someone builds a small application to bring together information scattered across several enterprise systems.
A function develops its own automations to manage hand-offs that established workflows don’t quite accommodate.
These activities build on years of citizen development, low-code tools and the humble spreadsheet, but what AI changes is the range and complexity of things people can create, and how quickly they can create them. The distance between recognising a problem and creating something to address it is getting shorter.
Much of this activity is valuable precisely because it happens close to the work. People understand the problems they are trying to solve, can experiment with different approaches and adapt their tools as their needs change. They don’t necessarily need a permanent enterprise application, or even a solution that would make sense to anyone outside their immediate team.
Yet organisations have good reasons to want visibility over what is being created. An application that accesses customer information, an agent that changes business records or an automation that coordinates a critical workflow can introduce dependencies and risks regardless of how long its creator expects to use it.
The familiar response is to bring these creations into the existing management system: establish ownership, document them, assess the risks, understand their dependencies and decide how they will be supported. But Gartner’s prediction raises a different question.
What if a growing proportion of these applications are never intended to become part of the permanent technology estate?
A project assistant might be extremely useful for six months, drawing together knowledge, coordinating activities and helping a team navigate a changing situation. When the project finishes, the organisation needs to retain the relevant records, decisions and learning. It may want to reuse some of the assistant’s components elsewhere. It doesn’t necessarily need to keep the assistant itself.
For leaders accustomed to treating adoption, scale and longevity as indicators of successful technology investment, this requires a shift in perspective. Some of the most valuable things their teams create may be valuable precisely because they are temporary.
And if that principle can apply to software, perhaps it can apply to more of the structures surrounding the work itself.
From changing systems to configuring around work
Organisations have always assembled temporary teams around particular needs. For example, product launches, acquisition or supplier disruption brings together people from different functions, often requiring them to coordinate information, decisions and activities across established organisational boundaries.
The difficulty is that the supporting technology and processes are rarely as flexible as the team itself. People negotiate access to information, adapt existing workflows and find ways to connect systems that were never designed to work together in quite this way. We have become remarkably good at working around the organisation we’ve built.
But instead, imagine a cross-functional team working alongside specialised AI agents, drawing on shared context, accessing enterprise data and coordinating activities through workflows created specifically for its current objective.
As the work progresses, the configuration changes. New agents or workflows are introduced as different challenges emerge. People join or leave as their expertise is needed. Some components prove useful enough to be reused elsewhere, while others disappear when their purpose has been served.
The team draws on capabilities that already exist across the enterprise without having to recreate them or inherit every aspect of the systems and processes through which they are currently delivered.
If the cost of creating and connecting the structures around work continues to fall, the organisation itself becomes more configurable.
This opens up the possibility of something we might call the ephemeral organisation: an enterprise capable of continuously forming and dissolving temporary structures around changing needs, while retaining the capabilities, knowledge and continuity that make those structures useful.
For leaders, the opportunity (and challenge) is to design an organisation in which temporary structures can form without having to rebuild everything they depend on.
Flexibility depends on what you make permanent
There is a paradox at the heart of this potential model - the more temporary the edges of the organisation become, the more deliberate its permanent core needs to be. If every new application requires someone to locate the right data, negotiate access, reconstruct the relevant business processes and establish who has authority to make decisions, very little has actually become easier.
Worse, we risk creating thousands of temporary solutions that each contain their own version of organisational knowledge, business logic and operating assumptions. When those solutions disappear, some of that knowledge disappears with them. When they persist, they introduce another collection of dependencies that somebody will eventually have to untangle.
The alternative is to become much clearer about which parts of the organisation should endure, independently of the particular technology, workflow or team through which they are expressed.
Let’s consider a capability such as supplier risk assessment.
The organisation needs to assess the reliability, financial health and operational risks associated with its suppliers. That capability may remain important for decades, even as the organisation changes its suppliers, operating model, technology and approach to risk.
Today, it might be delivered through a combination of enterprise applications, specialist teams, spreadsheets, external data providers and established approval processes.
Tomorrow, a temporary configuration of people, agents and software might be assembled to assess the risks associated with a particular supplier, region or disruption, drawing on existing enterprise data and coordinating the necessary analysis and decisions. The configuration might last a few weeks, but the underlying capability remains. For this to work, the organisation needs more than a clear understanding of its capabilities. It needs reliable building blocks that can be assembled in different ways: trusted data, reusable services, well-defined interfaces, shared context and common mechanisms for identity, permissions and governance. These become the enduring platform on which temporary applications, agents and workflows can be composed, without rebuilding their foundations each time.
This distinction between the capability and its current implementation becomes more important when the cost of creating new implementations falls.
There is a question of organisational time here, too. Different parts of an enterprise need to evolve at different speeds. A capability may endure for decades, while the teams, workflows and applications through which it is delivered change much more frequently. Historically, the cost of creating technology has encouraged organisations to support temporary work with permanent systems. AI creates the possibility of aligning the lifespan of the technology much more closely with the lifespan of the work itself.
For leaders, the challenge is to design the relationships between these different timescales, allowing temporary configurations to change rapidly without destabilising the capabilities on which they depend.
Rather than treating applications, workflows and reporting structures as the primary building blocks of the enterprise, leaders can identify the enduring capabilities beneath them: what the organisation needs to be able to do, what information those capabilities depend on, who is accountable for them and how they connect to other parts of the business.
This creates a more useful foundation for future applications, agents and workflows without assuming that today’s implementation is the only way the work can be done.
Of course, some processes and applications will continue to benefit from stability, standardisation and long-term investment. The point is to become more deliberate about which structures need to endure and which should have greater freedom to change.
Making this work requires a shared platform of reusable services and building blocks, with composability designed in from the start. This gives teams the flexibility to assemble and adapt disposable software without compromising organisational standards, security or control.
Design now for things you expect to disappear
A useful starting point is to look at the work already happening across the organisation and ask what would need to change if the technology supporting it were expected to last six months rather than six years.
Read on to discover three design priorities that become particularly important when going beyond understanding enduring capabilities.
