Mar 16, 2026
Somewhere in your organization, someone is building something right now that has been built three times before.
Jeroen Meijers
User Experience Designer
While Team A builds an interface in OutSystems, Team B is doing exactly the same thing. On their own little island, with their own budget. Why do we keep letting our most expensive experts reinvent the wheel?
I am Jeroen Meijers. As a frontend developer and UX expert at Team Resilience, I have seen closely where those delays come from.
You choose low-code because you want to advance quickly. Yet I often see the opposite happening. But what is causing that?
The backend is set up quickly, and the data is in order. But the actual delivery to the end user? That often experiences significant delays.
The real delay often doesn't lie in the technology or the skills of your developers. It lies in the absence of a central strategy for your frontend and UX.
Let's take a look at how that works (and goes wrong) in practice.
The Problem with the Islands
Large organizations often split their IT department into different teams. Team A handles the IT for the finance department, Team B for transport, Team C for inventory management. It makes sense, as it allows everyone to keep their focus.
However, in practice, this means that each team is building on its own little island. They are all working on their own application. In terms of the backend, this is often okay, as each team has its own data sources. But as soon as screens need to be built that a user looks at, a massive inefficiency arises due to duplicate development.
Let me make it concrete. Imagine five different teams need a table in their application to display data. A fairly standard component, you would say.
In the current situation, the following happens: Team A starts on their task (in Scrum terms: a 'story'). They see that they need a table. It doesn’t exist yet, so the developers have to build it themselves. They allocate a lot of 'story points' to it because they not only have to connect the data, but also need to fiddle with the formatting.
At the same time, Team B encounters exactly the same issue. They are also going to build that table. And so are Teams C, D, and E.
Now you have five teams that are all spending time and budget on building exactly the same component. The wheel is being reinvented five times. And the worst part is: that table probably looks slightly different each time because there is no alignment. This is not only a waste of time, but it also creates confusion for the end users who often work with multiple internal applications at the same time.
Developers don't want to 'pixel push'
There is also a human factor involved. Many OutSystems developers are primarily focused on the backend of applications: logic, databases, APIs. That is their strength. If you ask such a developer to worry about the exact shade of gray of a border or the whitespace between two buttons (we call that 'pixel pushing'), they generally don't feel happy about it.
As a result, this can lead to frustration in the team. The speed decreases, the 'story points' per task increase, because they dread the frontend work. And the quality of the interface does not improve either.
The solution: the central LEGO box
How do you solve this? By organizing the work centrally.
During my last project, I worked for a large logistics player. There, we established a central frontend team.
That team provided a theme that you can see as a large box with LEGO blocks. Inside that box are all the ready-made parts that the teams need.
The basics:
Colors, fonts, and corporate identity are set.The components:
We build that one table and other components. We ensure that it works perfectly, that you can put text, buttons, or icons in it, and that it looks good on mobile and desktop.The logic:
We think about how a menu unfolds or how a form reacts.
The effect on the work floor is gigantic. If Team A now needs that table, they no longer have to build it. They simply take the 'table' block from the central box.
Instead of counting 8 points for a task because they have to do the design themselves, it now might only cost them 2 points to put the data in. They don’t have to think about pixels; they only need to implement. This not only saves time, but it also makes the work much more enjoyable for those developers. They can focus on what they're good at: building functionality.
One bug fixed, benefits everywhere
There is another advantage of working centrally that is often forgotten: maintenance. Imagine there is a small error in that table we mentioned earlier. In the old situation, with the islands, each of the five teams had to dig into their own code to fix that. Searching five times , repairing five times.
With a central frontend, we fix it once in the core. All components are centrally managed. We fix the error, put it live, and all five applications take the improvements on immediately. The different teams no longer have to work on this themselves. Whether it's a technical error or an adjustment in the house style: you are agile across your entire organization.
Conclusion: dare to centralize
It may sound contradictory. You want autonomous teams that can move quickly. But by centrally managing one component, the frontend and UX, you give those teams the freedom to really accelerate.
You stop wasting talent on duplicate work. Your developers become happier because they don't have to design. And your end users get an application that not only works but also has a logical and recognizable structure.
Do you want to brainstorm about what such a 'LEGO box' could look like for your organization? I would love to think along with you about the first steps.
