.webp)
Most companies do not set out to build a fragmented digital ecosystem. It accumulates. One app at a time, one vendor contract at a time. The question of consolidation usually comes up only after a decade of digital growth, once the cost of running what you have starts to exceed the cost of improving it.
This is typical in sectors like utilities, banking, insurance, or automotive. These companies moved into digital early and have been evolving their products ever since. The average enterprise today manages dozens of applications, and only about a third of them are integrated. Most of that portfolio was not planned. It grew piece by piece.
Consolidation is often the first step towards something bigger. Once a company has one healthy product instead of five competing ones, that product can start to grow into an ecosystem of services, what many now call a super app. This article is about the first part, the consolidation, because it is the part many companies need to start with. My colleague Miloš Felix has written about how companies can build digital ecosystems.
When digital growth turns into operational complexity
In large energy companies, for example, the digital landscape is never just one application. Around the main consumer app you typically find a separate customer portal, a shared identity layer, and a range of standalone apps for loyalty programmes, solar monitoring, EV charging, or online payments.
This is what digital growth looks like after a decade of adding products. Each one was built for a reason. Together, they form a system where every change touches multiple teams and multiple backends.
For the result to feel like one product, all those systems, teams, and backend services have to work together. In an environment this complex, that is a real challenge.
At some point, every change becomes harder than it needs to be. Innovation slows down because the architecture stands in its way, and frustration builds.
I have worked with teams that spent more time coordinating between systems than actually building. That is usually the sign that consolidation is overdue.
According to 2023 Gartner data, IT maintenance reaches 60 to 80 percent of the total budget in many organisations. That leaves very little room for anything new.
The business case for consolidation is usually straightforward. The harder part is the transition.
Understand the ecosystem first, then build
When companies decide to move towards a one app strategy, the instinct is to start from scratch. In my experience, that rarely makes sense.
The first step is understanding how the current ecosystem actually works. Not how it was designed, but how it works today. In complex environments, the mobile app is only one layer. Behind it sit backend services, portals, identity management, and core systems handling contracts, payments, or consumption data.
In practice, that means answering a few questions honestly:
- Where do the mobile and web versions overlap?
- Which backend services can be reused instead of rebuilt?
- Where can data and integrations be merged?
- Which parts of the system create the highest operational cost?
Core services get reused and extended. Overlapping functionality gets unified. The product evolves around a shared foundation rather than as parallel applications.
The answers to these questions define the framework for the transition, which then has to be reflected in the technology and architecture.
How Škoda moved from multiple apps to one ecosystem
Škoda Auto is a good example of how this plays out in practice. Over time, several apps emerged: ŠKODA Connect, the MyŠKODA app, and OneApp. Each served a specific purpose, and each carried its own vendor assumptions and technical debt.
We took these apps over and, in agreement with the client, eventually unified them into a single product. That meant bringing core services closer together and aligning the architecture across platforms. The result is the MyŠKODA app, built on modern native technologies, with measurably better performance, reliability, and user experience.
A large part of the work was understanding which parts of the ecosystem could be reused, which needed to be extended, and which were only adding overhead without real benefit. That analysis can take longer than the development itself, and teams should not underestimate it.
One app strategy starts with a shared foundation
If everything is meant to work as one product, the same logic has to hold in the technology behind it. A one app strategy is closely tied to modern multiplatform approaches: a shared codebase, modular architecture, one set of code for iOS, Android, and WearOS.
The DoKapsy app by ČSOB is a good example. Its modular architecture lets individual services evolve on their own while staying part of one coherent product. Adding features or scaling the app no longer requires coordination across the whole system every time something changes.
Bringing everything into one app does not mean creating a uniform experience for everyone. A well-designed app responds to context. Based on login, role, or behaviour, it shows what is relevant for that user at that moment, whether they are a private customer, a business user, or someone just getting to know a new service.
If a company adds a customer data platform, the potential for personalisation goes a step further. But even without that layer, a single context-aware app typically drives higher engagement and better adoption than several separate apps competing for attention.
When a separate app still makes sense
There are situations where launching a standalone app is the right decision. Early-stage products need to test quickly, validate ideas, and develop without the constraints of an existing ecosystem.
With clients, I always look at whether this is a deliberate choice or an escape from complexity. Building separately for speed is a legitimate decision. Building separately because integration looks too complicated is a sign that the systemic questions may need answering again.
Most companies build their ecosystem gradually, whether they plan to or not. A unified approach creates a more sustainable foundation. Features built once can be reused, changes do not require company-wide coordination, and the experience stays consistent as the product and user base grow.
Consolidation is a big step, but rarely one that gets easier by waiting. If you are at that point, it is worth starting the conversation now.
.webp)
.webp)
.webp)
.webp)
.webp)
.jpg)
.jpg)
.png)
.avif)
.avif)
