Arbitr: from prototype to production
Building platform foundations and leading engineering delivery through a three-month launch, followed by continued migration and hardening.
- My role
- Engineering leadership and hands-on platform development
- Focus
- Architecture, service ownership, workflow consolidation and delivery
The problem
Our translation products had grown into several platforms with different interfaces and workflows. We needed a new platform that could bring the work together and support AI translation alongside human review.
Getting a working prototype was one part of the task. Turning it into a service that people could use meant dealing with data models, application boundaries, integrations, testing, deployment and migration. Existing business capabilities also needed to keep working during the transition.
My contribution
I built the early platform foundations and led engineering delivery, working with Product, Operations, Infrastructure and the engineers responsible for individual applications and services.
My hands-on work included the backend structure, shared configuration and models, API gateway, service patterns and messaging helpers. I helped establish the data model, database schema and technology stack, and stayed involved in frontend integration, testing and production readiness.
As the team joined the work, I gave engineers ownership of services and applications. Clear boundaries mattered: people needed enough context to make decisions and enough ownership to carry them through.
Some decisions that shaped the platform
Treat the prototype as a starting point. A demonstrable interface still needed work on security, architecture, testing and observability. I raised those gaps and worked through the frontend refactor and API integration with the team.
Simplify the workflows. We consolidated vendor-facing functions and organised the applications around client, internal-management and vendor needs. The goal was to preserve useful business functions while reducing the fragmentation around them.
Integrate existing capabilities deliberately. Machine translation, document services and other established capabilities were part of the wider system. A new platform architecture did not require us to recreate every useful service.
Release in stages and keep learning. AI translation and human-review workflows had different delivery needs. We worked through integration and testing issues as the platform progressed, and continued hardening it after the initial production milestones.
What reached production
The April–June 2026 build reached an end-of-June production milestone across the client, internal-management and vendor applications. The core translation and translation-plus-edit workflows were operating end to end by early July.
Customer migration and operational improvements continued after launch. That work included migration tooling, workflow visibility, release prioritisation and learning from production behaviour.
This was a team result. My role was to establish foundations, lead the engineering work, make technical decisions and help people take ownership, alongside the contributions of Product, Operations, Infrastructure and the wider team.
What I took from it
Simplicity needs repeated attention during a fast build. Clear service ownership, a shared understanding of the workflow and checks against the actual customer journey helped us make decisions as requirements evolved.
A launch is an important milestone. The work of understanding, operating and improving the system carries on afterwards.
Happy to talk through the decisions behind this work. Get in touch.