The Virtual Captive Team That Still Has Engineers From Year One
A UK FinTech company building AI and analytics software wanted a say in who joined its engineering team, and people who would still know its systems years later. It started small, scaled, and the account is still running today.
A virtual captive team, working inside one client's engineering organization
A UK-based FinTech company building AI and analytics software needed engineering capacity it could rely on for years, not a rotating set of contractors. The market would file this under offshore engineering teams, and the label is not wrong, it just misses the part that matters. What it has is a virtual captive team: a dedicated engineering team that works as the client's own, inside the client's own organization, under the direction of the client's own technical leadership.
The client took part in choosing the people who joined, so the team that formed was one it had picked rather than one it was handed.
That is the whole of the arrangement, and the reason it is worth writing down is how ordinary it has stayed. Roles have changed hands. The work has carried on. The people who learned this client's systems and practices are, in large part, still the people doing the work.
One continuous relationship, still running today.
Average tenure on the account.
Engineers from the account's first year, still on it.
Plus technical leads, developers and dedicated test engineers.
Three ways an offshore engineering team usually goes wrong
A company handing its platform work to an offshore engineering team is deciding three things at once, and each of them has a well-worn way of failing. These are the three. The rest of this page is what happened instead.
Knowledge that walks out of the door
Every time a contracted engineer rotates off, the understanding of how the systems actually behave leaves with them, and it gets rebuilt at the client's expense. On a platform that lives for years, that rebuilding repeats on somebody else's schedule, and the client pays for it twice: once for the work, and again for the ramp.
No say in who joins
A team can be agreed in principle and then staffed by people the client has never met. Developers arrive without test discipline beside them, and quality quietly becomes the client's own problem rather than part of what was bought. By the time the mismatch is visible, the team is already in place and working.
A layer between leadership and the work
When an outside vendor manages the team at arm's length, the client's own technical leadership stops directing the engineers doing the work and starts negotiating with an account manager about them instead. Direction gets relayed rather than given, and things go missing in the relay.
What a virtual captive team actually splits
Every arrangement of this kind divides the same two things between two parties: the work's direction, and the people doing it. Getting that division right is most of what makes a virtual captive team hold together. On this account it splits like this.
- Priorities and technical direction, day to day
- A say in who joins the team
- The pace and the shape of the work, and what gets built next
- A direct line to the engineers, with no account manager in between
- Finding the people, and keeping them on the account
- Their continuity across changes of role
- The pod they work in, and its lead
- Resolving it when a role changes hands
AnAr's engineers do the work; the client decides what work. The account runs as one pod with its own AnAr-staffed lead, reporting into the client's own leadership rather than into a layer at AnAr.
Why a virtual captive team holds where a contract team does not
Team composition on this account has changed over eight years. Roles have rotated in and out, and a departure has been replaced. Through all of it the work carried on without interruption, which is the only test that matters for a team embedded in somebody else's delivery. Retention is the mechanism underneath that: an account whose people stay does not spend its life re-learning the same systems.
Test engineering as a standing discipline, not a phase
The team works on a long-running software platform, AI and analytics software for financial services, evolving across multiple product cycles rather than shipped once and maintained. A platform that keeps changing keeps needing to be re-verified, so dedicated test engineering has sat on this account as its own discipline for its full history rather than being folded into the developers' own hours. The same holds for architecture: on a platform still being extended, design decisions keep arriving, and somebody senior has to be there when they do.
What the engagement puts in place, and what it means
The whole account in one place. We do not publish contract value, team size, or the number of people at each level, so what follows is what can be stated plainly, and what it means for the company the team works inside.
What is in place
Stated plainly, each one confirmed.
- An eight-year relationship, one continuous engagement, never restarted.
- Architect-level and technical-lead roles on the account, alongside developers and dedicated test engineers, for its full history.
- Average tenure of 4 to 5 years, with engineers from the account's first year still working on it.
- A client that took part in selecting the people who joined.
- One pod with its own AnAr-staffed lead, reporting into the client's technical leadership.
What it means
For the company the team works inside.
- Your systems and practices do not have to be re-explained to an unfamiliar face. The people who learned them are still the people doing the work.
- Quality is part of what you engaged, not something your own team absorbs later or discovers it owns.
- No account layer to work through. Your leads talk to the engineers, and the engineers answer to your leads.
- One accountable relationship for the people, rather than a set of individual hires to manage and replace.
- A team that started small and scaled as the engagement did, rather than one assembled at full size on day one.
Team Solutions is not a staffing contract with a headcount attached to it. It is one accountable team, chosen with the client, directed by the client, and held together by AnAr.
We evaluated a number of potential offshore technology providers to work cohesively with our London based team, and decided to partner with AnAr. Initially, we started small and scaled later. The AnAr team aligned themselves to our practices, and technology standards to meet our talent needs and delivery commitments. The offshore team has become an integral part of our overall operations and there has subsequently been a very smooth interaction between my entire team (onsite and offshore).
Founder & DirectorUK Based FinTech Company · AI and Analytics
A team is slow to build and quick to lose
AnAr Solutions has been building software and running dedicated engineering teams since 2014. Twelve years, more than 150 projects delivered, and 95% client retention. Those teams are a large part of what the retention figure is made of.
A dedicated team takes years to become genuinely valuable to the company it serves, and that value is held in people rather than in a contract. AnAr's half of the arrangement is the half that is easy to get wrong.
What this virtual captive team case study covers:
- The composition of the account, and what the client chose
- The split in full: what stays with the client, what AnAr answers for
- How the account held together across eight years of changing roles
- The client's own testimonial, in full
The PDF lands in your inbox in a minute. You get the case study to read and forward internally, not a sales sequence.
The full write-up, including the client's testimonial, as a PDF.
Working out how to set up a team in India? See Team Solutions →
Want the mechanics of how a dedicated team gets built and run? See Your team in India →
Prefer to talk it through? Contact our team →