SAPUI5 rarely makes headlines. It doesn’t change every few weeks, doesn’t chase trends, and doesn’t try to reinvent frontend development. Yet for large enterprises, it remains a core technology — one that quietly runs complex business processes used by thousands, sometimes millions, of people every day.

The People Behind SAPUI5 Expertise at LeverX

At LeverX, SAPUI5 is used by a team of more than 80 engineers working across multiple projects, industries, and regions. Over the years, this has formed not just a department, but a community: developers who have seen the framework evolve, worked through its limitations, adapted to its changes, and learned how it behaves in real production environments.

This article is based on interviews with Mikalai Samusevich, Senior SAPUI5 Developer, and Robert Baravik, SAPUI5 Team Lead. Both joined LeverX early in their careers and have been working with SAPUI5 here for more than 6 years.

Their stories offer a practical view of what SAPUI5 development looks like at scale — and what keeps people growing inside one company for so long.

Starting From Scratch — and Staying

Neither Mikalai nor Robert joined LeverX as experienced SAPUI5 engineers. Both came through internal SAPUI5 courses that the company has been running for years.

Robert describes LeverX as his first major company. While studying at university, he was learning programming on his own, taking online courses and trying different options. At some point, he noticed LeverX’s SAPUI5 training program — a small group format with a clear outcome: successful graduates would join the company.

The courses didn’t promise shortcuts. As Robert recalls, the expectation was simple: study seriously, complete the program, and keep developing. That was enough to get started.

After joining, his path followed a pattern common inside the team. First came mentorship and internal projects, then production work, then responsibility for other developers. Over time, Robert became an informal leader and later a Team Lead, supporting several teams at once.

Mikalai’s path followed a similar trajectory. He also joined through internal training, worked under mentorship, and gradually moved into senior responsibilities. Later, he began mentoring others and teaching SAPUI5 courses himself.

Robert describes this cycle directly:

“I later conducted several SAPUI5 course intakes myself — kind of giving back to the company for bringing me in this way.”

That loop — learning, applying knowledge on real projects, and then sharing your experience with others — has become one of the defining characteristics of the SAPUI5 team at LeverX.

What SAPUI5 Work Actually Looks Like

From the outside, SAPUI5 work is sometimes imagined as overly standardized. As Robert emphasizes, there’s more nuance to it. A developer’s day depends heavily on the stage of the sprint and the type of project. Mornings often start with emails, notifications, and ticket updates — including tickets created for SAPUI5 framework issues themselves.

Because SAPUI5 is deeply integrated into SAP’s ecosystem, developers frequently encounter situations where a task depends on a framework-level fix. Robert mentions that it’s common to start the day by checking whether a SAPUI5 core issue has been resolved, because further work may depend on it.

He also notes a key difference between SAPUI5 and many other frontend frameworks:

“You focus less on frontend in the classic sense — CSS, custom components — and more on business logic and correct implementation of what the framework already provides.”

In practice, that means spending more time understanding business processes, data models, and system behavior. For developers, this can be challenging at first, especially early in their careers. Over time, however, it allows them to see the full lifecycle of an application and understand how their code affects real users.

From Stable Versions to Constant Updates

Over the past few years, SAPUI5 projects at LeverX have definitely shifted and evolved. Earlier projects often ran on long-term stable versions, typically using OData V2. Migration was slower, and changes were incremental. According to Robert, this has changed noticeably.

Today, most projects he encounters use recent or near-latest SAPUI5 versions and OData V4. On SAP-standard projects, framework updates can happen automatically — sometimes nightly — without direct control from the development team.

As Robert explains, this forces developers to stay alert:

“Once every couple of sprints, you go to the documentation to see what changed, what’s deprecated, what new samples or controls appeared.”

At first, this pace can feel uncomfortable. Over time, developers adapt and begin writing code with framework evolution in mind. According to Robert, this leads to better, more future-proof solutions.

When Standard Components Aren’t Enough

Despite the framework’s extensive component library, there are cases where standard controls don’t meet business requirements.

Robert describes several technically demanding tasks he’s worked on in recent years. One example involved building a large custom table control with Excel-like behavior — formulas, filtering, sorting, copying data, and handling performance constraints for thousands of rows.

Another case required synchronizing application state across multiple browser windows. The customer’s employees worked with two large monitors and wanted the same application page open twice, scrolled differently, while edits in one window instantly appeared in the other.

Solving this required a combination of draft-saving mechanisms, browser events, state synchronization, and careful handling of security constraints.

These tasks, Robert notes, usually emerge from real customer needs:

“Interesting technical challenges usually grow out of specific business requirements.”

Alongside custom controls, developers regularly deal with complex integrations, navigation between systems, performance bottlenecks, and architectural decisions that go far beyond routine CRUD work.

Working With Enterprise-Scale Clients

Large clients introduce a different level of responsibility. Robert explains that for enterprise customers, system scale is not a theoretical concern — it defines the project from the start.

Discussions often move quickly from implementation details to concrete KPIs: expected load, response times, system stability, and failure scenarios. Testing requirements are correspondingly high, with coverage expectations often reaching 80–90% or more across unit, integration, and end-to-end tests.

Developers also gain exposure to complex CI/CD setups, multiple environments, and strict deployment processes. Even when dedicated DevOps engineers handle infrastructure, frontend developers need to understand how the system is assembled and deployed to work effectively.

According to Robert, this depth is part of the appeal:

“You start to understand why things are built the way they are.”

A Large Team, Shared Knowledge

With more than 80 SAPUI5 Developers, LeverX relies heavily on internal knowledge sharing: for instance, internal chats where developers discuss edge cases, framework behavior, logs, and architectural decisions.

Robert describes how almost every day someone asks whether others have encountered a specific issue — sometimes related to very old stacks, sometimes to brand-new services. In many cases, someone else has already faced a similar problem.

This daily exchange is reinforced by internal meetups and lectures. Developers organize sessions on new SAP services, BTP modules, development processes, and framework updates. Many sessions include live coding and practical examples, and recordings are shared for those who can’t attend.

Robert is direct about the impact:

“If this chat didn’t exist, everyone would just keep their experience to themselves.”

Over time, this creates a shared technical baseline across the department, even though developers work on different projects.

Processes, Onboarding, and Continuity

One area Robert highlights is internal education around processes. He recalls a series of lectures that explained SAP-standard project workflows in detail — system setup, CI/CD, approvals, and dependencies between tools.

Later, when he joined a SAP-standard project, the transition felt familiar. The workflows were already known, and onboarding was smoother.

That continuity matters in a large team where developers may switch projects over time. Internal documentation and education reduce friction and allow developers to focus on solving problems rather than learning processes from scratch.

Culture, Boundaries, and Well-Being

Both Robert and Mikalai describe a working environment built around flexibility, clear boundaries, and mutual respect. Working hours are flexible, without strict control over arrival times, which Mikalai appreciates. He also found that working from the office helps maintain a healthy work-life balance.

“When you leave the office, work stays at work. You get into your car and switch off.”

Day-to-day work follows a calm rhythm: planning tasks, meetings, and informal conversations with colleagues. Operational topics like vacations or sick leave are handled through internal systems, keeping things predictable. Over time, Mikalai learned to manage workload more consciously.

“You can’t earn all the money — you have to think about yourself sometimes.”

Outside work, he stays active through boxing, which helps him fully disconnect and recharge.

Why People Stay

After more than five years at LeverX, Robert says he has never seriously considered leaving. Competitive compensation matters, and so does continuous technical development.

He points out that many developers joining from the market have spent years on projects where technologies barely changed. Inside LeverX, exposure to modern SAPUI5 approaches — such as Fiori Elements and newer framework versions — happens relatively quickly.

Robert sees this growth firsthand in his team:

“People come in not knowing some of these things at all, and after a few months, they already work with them confidently.”

For developers who want to stay in the SAPUI5 ecosystem while continuing to grow technically, this combination of project scale, shared expertise, and long-term stability has proven sustainable.

A Team Shaped by Experience

The SAPUI5 team at LeverX didn’t form overnight. It grew gradually, through projects, internal training, mistakes, fixes, and years of accumulated experience.

Today, it is a large group of engineers who know the framework not just from documentation, but from real systems running in production. Their expertise is shaped by enterprise constraints, evolving technology, and constant collaboration with each other.

For SAPUI5 Developers, that combination defines what working at scale really means.