Lynx Beleggen.

A next-generation trading platform that launched with 3 bug reports. Two of them were a missing color in the dark mode we added. A senior frontend team that still runs the architecture years later. And new hires making commits at the end of their first day.

The Situation

Lynx Beleggen operates an online trading platform serving retail investors across Europe. Trading platforms are unforgiving environments. Users are making financial decisions in real time, watching tickers move, placing orders, and managing positions. The frontend isn’t a wrapper around an API. It is the product. If the interface feels slow, unclear, or unreliable, users take their money elsewhere.

The platform had been built and maintained by a team whose strengths were on the backend and infrastructure side. The trading engine and infrastructure were solid, but the frontend had grown without dedicated frontend expertise. It showed in the user experience: inconsistent interfaces, redundant functionality spread across pages, and a look and feel that didn’t reflect the quality of what was running underneath.

The codebase had reached a point where the team was spending more time working around existing code than building anything new. The frontend was built on AngularJS, a framework that had been end-of-life since 2021. The aging dependency tree was becoming a liability the company couldn’t afford to ignore. Lynx recognized they needed specialized frontend leadership to move the platform forward.

The engagement ran two years and split into two distinct phases.

Rescue & Recovery

Lynx had a visual rebrand ready to launch, but the frontend was the bottleneck. The existing CSS architecture was so tangled that the team couldn’t figure out where to begin. Styles were scattered, overrides were layered on overrides, and changing one thing risked breaking something three screens away. The rebrand was stuck.

We unblocked it by rebuilding the entire UI layer from scratch. But we didn’t stop at applying new colors. Working closely with the UX/UI design team, we audited every screen on the platform and used the rebrand as an opportunity to fix deeper problems. Redundant pages were consolidated. Duplicate functionality was merged. Interaction patterns were reworked to be consistent across the application. We added proper animations and transitions that gave the interface the responsiveness and polish a financial product demands.

The rebrand launched on schedule.

Architecture & Modernization

With the immediate visual and UX problems solved, we turned to the fundamental constraints. The existing framework couldn’t be incrementally migrated to where the product needed to go. This was a platform handling real money in real time. The architecture needed to be right, not just right now, but for the years of feature development that would follow.

We designed and built the next-generation frontend from the ground up. The most complex challenge was real-time state: tickers updating continuously, order placement requiring instant feedback, and portfolio positions shifting as markets move. All of this streaming concurrently over WebSockets, all needing to stay perfectly synchronized, and all while keeping the interface responsive and accurate.

We collaborated closely with the UX/UI design team throughout the rebuild. On a trading platform, design decisions are trust decisions. The placement of a confirmation dialog, the speed of a loading state, the clarity of an order summary: these aren’t cosmetic choices. They determine whether a user feels confident enough to act. Every screen was designed to be fast, clear, and reliable, because in fintech, confusion costs real money.

Team Building & Leadership

A new architecture is only as durable as the team that maintains it. We designed the codebase, the tooling, and the development workflow so that a new engineer could clone the repo and ship meaningful work on day one. Clear module boundaries, documented patterns, and a development environment that just works.

We recruited senior frontend engineers to own the platform going forward. New engineers were making commits at the end of their first day. Not because we rushed onboarding, but because the architecture was designed for it. Every decision we made about code structure, naming, and documentation was tested against one question: could someone new understand this without us in the room?

The Result

The rebranded platform launched on time, unblocking a company milestone that had been stalled by the frontend. The next-generation platform launched with three bug reports from customers. Two of them were a missing color in the dark mode we added. Customers loved the dark mode.

The engineers we recruited are still there, still running on the architecture we built. New hires still make commits on their first day. That’s what a well-designed architecture looks like in practice: not just fast to build on, but fast to learn.

A platform that had outgrown its original frontend now runs on a modern, real-time architecture built for the next phase of the product. The team owns it completely. That was always the plan.