Somewhere in your organisation this quarter, someone built an application without asking IT. They described what they needed, an AI wrote it, and it worked. They’re proud of it, and they should be. It solved a real problem in days instead of quarters.
Multiply that by every department, every quarter, for the next three years.
That’s the number worth thinking about. Not because the applications are bad. Because each one quietly creates an obligation that nobody priced, nobody staffed and nobody put on a risk register.
A business application that people depend on carries a standing set of requirements. You might think about the following needs. Separated environments, so changes can be tested before they hit production. Backup and a tested restore. Controlled change, with a record of who changed what. Documentation that still matches reality. An audit trail that answers questions a regulator or an external auditor will eventually ask. A permissions model. An upgrade path. Somebody who understands it after the person who built it has moved on.
None of that appears in the demo. All of it appears in the budget eventually, usually as unplanned work, and occasionally as an incident.
Built per application, these obligations scale linearly with your portfolio. Forty applications means forty backup conversations, forty deployment routines, forty documentation efforts and forty opportunities to discover that the only person who understood something has left. The cost of running the portfolio starts growing faster than the portfolio itself.
The alternative is to build on a platform where these services exist once, at the platform level, and every application inherits them. We take WEBCON as example as we know its capabilities best.
The practical effects are worth stating in business terms:
Change stops being an event
Because the platform holds the state of every running process as structured data, a process definition can be changed while instances are still in flight. An approval step gets added and the four hundred requests already in progress carry on, with their history intact. There is no downtime, no migration project and no release window to wait for. The consequence is behavioural more than technical: improvements stop being deferred, and the backlog of things nobody wants to touch stops compounding.
Audit readiness becomes a byproduct. Every instance records every step, every decision, every field change and every document version automatically, because the engine does it for all applications rather than because someone configured it for one. An audit becomes a reporting exercise rather than a reconstruction project.
One operating model covers the whole portfolio. One backup policy. One permission model tied to your existing identity provider. One upgrade that lifts every application at once, with long-running cases surviving the version change. One set of skills, so people can support applications they didn’t build. The eightieth application costs meaningfully less to operate than the first, which is the opposite of how bespoke portfolios behave.
Documentation is generated from the system itself, which removes the most common reason documentation is useless, namely that it describes a version of the process that no longer exists.
Two things are true at once.
AI genuinely compresses delivery. Used inside a governed platform, it classifies documents, extracts data from invoices, drafts process structures and summarises long cases, with a person in the loop where the decision matters and the result landing in the same audit trail as everything else. The platform stays model-agnostic, so you choose your provider rather than inheriting someone else’s.
AI also compresses the time it takes to create ungoverned liabilities. The constraint that used to limit how many unmanaged applications your organisation could accumulate was the difficulty of building them. That constraint is gone. What remains is whether the things being built land somewhere they can be operated.
There’s a second-order point that matters more than it looks. Most AI initiatives stall on data quality. Organisations that have been running processes on a governed platform for a few years have been generating clean, structured, contextual data about how work actually happens, without running a programme to do it. That’s the raw material for everything from process mining to decision support, and it accumulates whether or not you have an AI strategy yet.
Deployment is a choice rather than a constraint: cloud or on-premises, with the vendor based in Europe. For organisations working through data residency, sovereignty and supply chain questions, that keeps an option open that several alternatives close.
It does not supply discipline. Process ownership is still a decision someone has to make. Production still has to be kept clean, because the moment people start making manual changes there, the governance model stops meaning anything. Restores still have to be tested rather than assumed. And a platform purchased without a plan for how applications get prioritised, approved and owned will produce sprawl with better logging.
The platform removes the repeated engineering. It doesn’t remove the management.
If the answers are uncomfortable, the problem isn’t that your people are building too much. It’s that they’re building somewhere that makes you pay for it twice.
Would you like to discuss this further, or do you recognise these challenges within your organisation? Get in touch and let’s find out together.
