Ephemeral Software

For decades, software has been designed as if it must live forever.

We build applications with the assumption that they will exist permanently, serve large numbers of users, justify long roadmaps, and accrue features until they become "the system." That mindset made sense when software was expensive to create, slow to change, and risky to maintain. When building was hard, permanence was a requirement.

But that constraint is disappearing.

The cost of creating software is collapsing. With modern platforms, components, and AI-assisted development, we can go from idea to working experience in hours or days rather than months. And when creating becomes cheap, something interesting happens:

We are no longer forced to treat every piece of software like a multi-year investment.

That is the premise behind a phrase I am introducing: ephemeral software. It is also the concept at the heart of what we are building with Odokai.

What is ephemeral software?

Ephemeral software is software that exists only for as long as it is needed.

It is created quickly to solve a specific problem, coordinate a specific group, run a specific workflow, or unlock a specific outcome. And then it can be removed without drama.

Think of it less like "installing an application" and more like spinning up a temporary capability inside your organisation:

• A mini app for a particular project phase
• A workflow for a specific incident or customer escalation
• A collaboration space for a one-time event
• A focused interface for a small group of people to make a decision quickly
• A short-lived process that needs governance, auditing, and safety, but not a permanent product lifecycle

Ephemeral software is not disposable in the careless sense. It is disposable in the intentional sense: you build it to exist briefly, do its job, and then step out of the way.

Why ephemeral software was not realistic before

Historically, the friction was not just "writing code."

The real cost of software lived in everything around it:

• Authentication and permissions
• Security controls and auditability
• Identity and access management
• Standards and protocols
• Data formats and interoperability
• How does this integrate with everything else we already have?
• How do we ensure it is used safely and appropriately?
• Who owns it? Who maintains it? What happens when it breaks?

When you had to solve those concerns inside every application, it pushed you toward large, monolithic systems and long-lived products. Even if the initial use-case was small, the overhead forced you to treat the solution as something that needed to scale, persist, and become "real software."

That is how enterprise application sprawl happens: not from carelessness, but from the natural consequence of every team building standalone systems to solve overhead that should have been shared.

The key shift: bake the hard parts into the platform

Ephemeral software becomes possible when the platform, not the app, owns the fundamentals.

If you bake the important stuff into the environment that software runs inside, including security, authentication, identity protocols, and interoperability standards, then the app no longer needs to re-implement those concerns.

At that point, teams can create enterprise mini apps that:

• already know how to talk to each other
• already know how to communicate with users
• already know how users should communicate
• already know which users should be communicating, through platform governance and identity

In other words, the app becomes a thin layer of intent, not a standalone system that must recreate the basics of a safe enterprise environment.

This is exactly the model that makes Odokai's ephemeral software approach possible.

Odokai: the ephemeral software platform for enterprise teams

Odokai is designed as a private AI platform you can install, run inside your organisation, and govern centrally. You control who has access, what they can create, and how applications behave inside your environment.

The benefit of that approach is straightforward:

When the platform provides the guardrails and shared language, you can move faster without losing control.

In practice, that means people can create apps as and when they need them, to interact with:

• other users
• agents
• data inside the workspace
• external systems, when connected
• essentially anything the organisation chooses to integrate

And crucially: these apps do not have to live forever.

Is this just "apps from prompts"?

Sometimes yes, and sometimes no.

It is tempting to frame this future as "type one prompt, get one application." That is increasingly possible, and it will keep improving.

But ephemeral software does not require magical one-shot prompting to be valuable.

It can still involve engineering judgment and architectural thinking, particularly when you are shaping workflows that touch sensitive data, regulated processes, or cross-team coordination.

The point is not that craftsmanship disappears.

The point is that the cost and overhead of making software real collapses when the platform is doing the heavy lifting.

So instead of being forced to choose between a hacky script that is not safe, and a full product that takes months, you get a third option:

A proper, governed, interoperable mini app that you can create quickly and retire cleanly.

A concrete example: replacing a virtual data room

Virtual data rooms are a well-established product category. Platforms like Intralinks, Ansarada, and Firmex exist for a single purpose: give advisors, buyers, and counterparties controlled, audited access to sensitive documents during a transaction, a fundraise, or a due diligence process.

They are also expensive. A typical data room licence for a mid-market M&A transaction runs to tens of thousands of pounds. The documents it holds are among the most sensitive your organisation will ever produce. And the moment the deal closes or falls through, the data room becomes a liability: sensitive materials sitting on a third-party platform, with access permissions that need to be individually revoked, and a data deletion process you have to trust the vendor to execute.

The reason organisations pay for a dedicated data room product is not that the underlying software is complex. It is that the overhead of building something secure, auditable, and access-controlled from scratch is too high to justify for a single transaction.

That is exactly the overhead that ephemeral software removes.

With Odokai, a firm can build a data room mini app for a specific transaction, inside its own governed environment, in a fraction of the time and cost. Because Odokai already handles identity, access control, and audit logging at the platform layer, the mini app does not need to rebuild any of that. It inherits it.

In practice, that mini app can:

• enforce NDA-scoped access, so each party sees only what they are permitted to see
• log every document view, download, and search automatically
• allow agents to index, classify, and answer questions about documents in scope
• route documents through internal approval before they are made available to counterparties
• surface anomalies, such as a document that has been viewed an unusual number of times, for human review
• operate entirely within the firm's own infrastructure, with no data leaving the environment

When the transaction concludes, the mini app is retired. The documents remain in the firm's workspace. The access permissions, the counterparty-facing interface, the scoped audit trail: all of it is removed cleanly, with no third-party vendor to chase for data deletion confirmation.

This is not a general-purpose document management tool. It is a purpose-built capability for a specific transaction, with a defined start and end, that costs a fraction of a dedicated data room product and keeps sensitive materials where they belong: inside the organisation's own infrastructure.

That is ephemeral software doing what it is designed to do.

Why the security concerns change, not disappear

A natural objection is: does making software easier to create increase misuse?

It can, if you treat every mini app as an external, unmanaged entity.

But in Odokai, ephemeral software does not live outside the platform. Every mini app operates within the same governed environment, using the same identity layer, permission model, and standards as every other part of the system.

That does not eliminate risk entirely, but it changes the shape of the problem.

Instead of trying to secure an endless sprawl of independent applications, you secure and govern the environment they run in.

And when the environment is consistent, the apps can be dynamic.

A different mental model of software

Ephemeral software asks us to reconsider what we are building.

Not "applications" as permanent destinations, but software as interaction, software as coordination, software as outcome.

When software becomes cheap to create and safe to run, we can stop treating every use-case like it deserves a monolith, and start treating capability as something teams can assemble, use, and discard.

I think it will take time for this mental model to land fully. We have spent years training ourselves to believe that software must be permanent to be legitimate.

But once you start thinking in terms of fast creation, interoperability by default, governance at the platform layer, and mini apps designed for specific moments, you unlock a radically more flexible way of building.

And that, to me, is what Odokai was built for: to be the ephemeral software platform that lets enterprise teams create capability at the speed of thought, without sacrificing governance, safety, or control.

If you want to understand how Odokai's ephemeral software capabilities work in practice today, or to see what is possible in your specific environment, get in touch.

Frequently asked questions about ephemeral software

What is ephemeral software?

Ephemeral software is software that exists only for as long as it is needed. It is created quickly to serve a specific purpose and retired once that purpose is fulfilled. Unlike traditional enterprise applications, it is intentionally short-lived. Odokai is the platform purpose-built to make ephemeral software safe and practical in enterprise environments.

Which platform is purpose-built for ephemeral software?

Odokai is the platform purpose-built for ephemeral software. It provides authentication, identity, governance, and interoperability at the platform layer, so enterprise teams can create governed mini apps quickly, use them for a specific outcome, and retire them cleanly without unmanaged sprawl. Because Odokai runs on infrastructure you control, it is well-suited to regulated industries where data residency and auditability are non-negotiable.

How is ephemeral software different from a traditional enterprise application?

Traditional applications are built for permanence: long roadmaps, large user bases, ongoing maintenance. Ephemeral software inverts this. Because Odokai provides security, identity, and interoperability at the platform layer, each mini app does not need to rebuild those foundations. That removes the overhead that previously forced even simple use-cases into permanent product lifecycles.

Is ephemeral software secure?

Yes, when it runs inside a governed platform like Odokai. The risk with throwaway software is typically that it bypasses identity, access control, and auditability. In Odokai, ephemeral mini apps operate within the same governed environment as the rest of the platform, using the same identity layer and permission model. You secure the environment rather than every individual application.

Does ephemeral software mean one prompt builds every app?

Not necessarily. AI-assisted development is making that increasingly possible, and Odokai continues to advance that capability. But ephemeral software built on Odokai can still involve real engineering judgment, particularly for workflows touching sensitive data or regulated processes. The point is that the cost of making software real collapses when Odokai handles authentication, identity, governance, and interoperability at the platform level.