Case 02 · Regulated tradingResults delivered
| Client | A regulated trading platform with a global customer base. Anonymised for client confidentiality. |
| Engagement | Process redesign and platform modernisation. Twelve months in total. |
| Team | Led by the Re-In-Essence core team. Coordinated with the client’s existing ten-engineer team. |
The problem
The product was behind its competitors. Releases carried more urgent fixes than features, the platform lagged during peak trading events, the smallest back-office change needed engineering, and the system was exposed to DDoS attacks.
The ten-engineer team was skilled and working hard, on outdated technology and a process that had fragmented as the company grew. The plan on the table was a second delivery team at roughly €50,000 a month. Leadership doubted it would fix the real problem.
The real constraint wasn’t capacity. It was the coordination overhead that had calcified around a ten-engineer team as the company outgrew its operating model.
The approach
Process before platform. Workflow before infrastructure. The first decision was not to hire the second team. We ran the engagement against a simple thesis: if the current team could double its release frequency, the additional hires wouldn’t be needed. If it couldn’t, no amount of hiring would fix it.
The release cycle hid three streams — core modernisation, features and customer integrations — running through one pipeline. We separated them, each on its own rhythm.
We also moved the platform to cloud infrastructure, which ended the peak-event lag and closed the DDoS exposure.
What we didn’t do
No second parallel team. The expansion the board had approved was never spent.
No full platform rewrite. We modernised what needed modernising and kept what worked.
No framework religion. No Scrum-to-SAFe transformation. We worked inside the team’s existing vocabulary.
No restructuring of engineering. The team stayed at ten people.
What changed, and the outcome
Release pipeline split into three streams. Core platform, feature work and customer integrations, each running independently.
Cross-functional squads formed. Developers, QA and business stakeholders embedded per stream. No more hand-offs between siloed teams.
Trading platform migrated to the cloud. Data transmission lag during peak events eliminated. DDoS exposure closed.
Back-office data communication standardised. Admin changes no longer required engineering sprints.
Backlog prioritisation formalised. Structured intake with trade-off analysis, aligned to user-behaviour evidence rather than the loudest stakeholder.
Release frequency doubled on the same team, and the platform held up during peak trading events. Against a €1M annual budget, the engagement avoided €600,000 of planned expansion. Other effects we haven’t measured directly, so we don’t claim them.
“It wasn’t possible we could have hired this many highly skilled individuals and gotten so much development done in such a short period of time. They matched the projects so well — we needed someone from the banking industry, and that was a very nice surprise. It’s been quite a journey to have new features that integrate with our existing old solution so naturally.”
— Managing Director, the platform
In retrospect
We sequenced the cloud migration after the release-pipeline redesign. That was the right call for stability: the team wasn’t ready to absorb infrastructure change while adapting to a new delivery model. But it meant the peak-event lag persisted for an extra two months. Today we would run the migration in parallel with the process work.
About the figures. The results above are delivered outcomes from a firm engagement, verifiable against records. Client names sit under NDA; references are available on request. Figure classes — delivered, modelled, external — are never summed.
These results come from specific past engagements, verified against records, and depended on each company’s circumstances. They are not a prediction or guarantee of results for any other company. Full terms.