90.4% of companies using low-code reported increased developer productivity. Many companies want to empower their developers to create solutions quickly in order to digitize and automate. But sometimes solutions get stuck in a PoC/MVP stage for various reasons.
This is when you ask yourself, among other things, whether you should have chosen a low-code platform with management. To achieve a good implementation project, you should also consider which requirements are right and what you should digitize and automate.
Power Apps as an example
Microsoft Power Apps is a good example of just such a “test bed”. Microsoft describes Power Apps as a way to quickly build business apps that are connected to data and services, which allows many to go from idea to working flow quickly. Low-code is just quick to get on the track and we at Multisoft usually say that we are 5-20 times faster.
And when you're in the middle of a daily routine with bottlenecks, manual tasks, and "we should really automate this" lists, that's often exactly the kind of speed you need.
But in large companies, something predictable happens when the test actually works: the PoC spreads. More teams want to automate, and exceptions and deviations increase. Data and integrations grow. And suddenly it's no longer a PoC, but a system support that people lean on to get the job done.
Then the question is no longer whether you can automate, but whether what you have built can be managed without becoming a drag.
Ving as an example
A Commercial Analytics & Automation Specialist at the travel company Ving (Nordic Leisure Travel Group) recognises the development that many organisations are going through right now. Low-code and no-code tools mean that more people than before can build their own solutions within the business. The threshold for creating something functional has become significantly lower.
“Today, practically anyone can build almost anything in a low-code tool, as long as the interest is there.”
This means that more ideas can be tested more quickly and that initiatives can emerge directly within the business. But according to him, the challenge no longer lies in creating the application itself.
“The challenge lies in scalability, operational reliability, security, costs, and further development. All the things that become difficult when there is no proper long-term management in place.”
Today, Ving uses a Softadmin platform that has been tailored to its needs. The platform has added 33 new system capabilities, but that does not prevent further experiments and testing, both within and outside the platform.
When the pilot starts to become business critical
There is a clear tipping point where you notice that the solution starts to behave like a “real system.” Often these feel like small annoyances at first, but they usually have the same thing in common: You have gone from experiment to operation, without the lifecycle having caught up.
Here are some typical signals:
- More users than planned and suddenly many who “have to” be able to work, even if something goes wrong.
- Changes take longer than they should , because each adjustment affects more parts.
- Personal addictions creep in: "Ask X, he built that one."
- Integrations and data become the difficult part , not the interface itself.
- Many similar apps are starting to appear, with similar logic but different owners.
This is not a failure. Rather, it is an acknowledgement that you have found one or more processes that are important enough to address, but that now need to be treated as a system, not an experiment.
The hidden cost: automation debt and personal dependencies
A PoC is often built with one priority: Quick Value. But as it grows, what were “reasonable shortcuts” can become a form of debt. It’s noticeable when you need to change something and discover that everything fits together in unexpected ways.
Forrester has likened technical debt to “death by a thousand cuts”, not one big disaster, but many small decisions that individually feel defensive but that collectively become expensive and risky.
This mechanic is also recognized in low-code environments when solutions become mission-critical: Every little special rule, every quick connection, every “we'll document it later” becomes interest you pay in rate of change and stability.
Person dependency is often the next blow. In the beginning, it is normal for a person to have the big picture. In a critical situation, it is a vulnerability. If you notice that you are avoiding changes because “only X dares to touch that one”, you are already past the PoC stage.
When the system map takes over: data, integrations and traceability
In large organizations, it is rarely the “app” that is the difficult part. The challenge is making it work in the system landscape.
It usually becomes clear when the solution needs to be completed:
- Retrieve and write data across multiple systems.
- Manage master data in a consistent manner.
- Provide traceability (who did what, when and why).
- Clear permissions at multiple levels.
Here you are in practice in a classic system problem. It is often in this phase that you notice that you are no longer building an interface, but a framework, an integration pattern and an operable flow.
And at the same time , “app sprawl” can creep in: multiple teams building variations of the same thing. It may feel innovative, but without structure, it becomes difficult to know what is standard, what is local, and which solutions are actually safe to scale.
Or “shadow automation” : When employees or teams build their own automation flows without common standards, you easily end up with a “shadow” of automation that no one really owns.
From Excel to Power Apps to system support
Some are in Excel, some have taken the step to, for example, Power Apps, and some want to take the next step. Many organizations feel good about seeing this as a maturation journey:
- First: Identify and prove the value.
- Then: Standardize and create common building blocks.
- Finally: Industrialize what has become important.
This is where the “next step” comes in. Not as a comparison that says Power Apps is wrong, but as a logical continuation: When a solution is going to live for several years, withstand change, handle more integrations and have clear management, then you often need a platform, working method and supplier that is built for just that.
In Multisoft's world, this is often when Softadmin® becomes relevant: When you want to maintain pace and agility, but want to move from "we have a working app" to "we have a system support that can be owned, operated and developed long-term". A low-code platform that you don't have to build and maintain yourself.
A simple rule of thumb: When is it time to take the next step?
If you want pragmatic decision support (without making it a major investigation), you can start with three questions:
- How expensive is a downtime? (and how quickly do you have to be able to restore?)
- How often do you have to change the process? (and how much testing/release does it require?)
- How many dependencies do you have? (integrations, data, permissions and reporting)
If the answer is “this is important, frequent, and connected,” then you are rarely left in PoC land anymore.
All credit to Microsoft, but…
Many see Multisoft and Softadmin® as a natural next step when a solution needs to become more long-term manageable. Power Apps often works well for quick pilots, departmental tools and solutions that are close to Microsoft 365, but when you start to scale up, licenses and premium features can quickly drive up costs. Many then want to find an alternative that is still close to the Microsoft world (Multisoft is a partner of Microsoft), but where the cost picture is not primarily linked to licenses per user or app.
Power Apps is often the strongest within Microsoft's own ecosystem. When you need to connect multiple systems outside of that realm, or when you need to keep multiple apps, versions, and compliance requirements together, governance and oversight can become a challenge.
It becomes especially clear when workflows grow in complexity and begin to involve people, multiple systems and processes that run over a longer period of time, that a flow-based approach is not always enough all the way through.
In this phase, integrations and scalability often become crucial. Being able to connect both legacy systems and modern tools that business processes depend on becomes central, and as your business grows, you need a platform that can handle large amounts of data, high loads, and long-running processes in a stable manner.
Equally important is that compliance and governance are in place from the start, with role-based permissions that make it clear who gets to see what and do what, and that can be managed over time.
