Dedicated Development Team Case Study

The challenge

Optimus builds an automation platform for financial operations, the reconciliation of payments, the validation of fees and the preparation of a financial close, sold to enterprises and financial institutions. A product company of that kind has a particular staffing problem. The roadmap does not arrive in evenly sized pieces, so the front end needs more capacity in some quarters than the permanent team justifies carrying in the others, and the work is product work rather than a discrete project with a handover at the end of it. Engaging an agency to build and deliver something would have created exactly the wrong artefact, a body of code written outside the team that owns it, arriving with its own conventions and its own assumptions about how the rest of the product works.

The approach

We supplied Next.js developers into the client's own repository rather than into a separate one. They commit to the same branches as the client's staff, are reviewed by the client's reviewers and follow the conventions already in the codebase. There is no handover event, because there is nothing to hand over. This is the arrangement we describe as team extension rather than outsourcing, and the distinction is not a matter of vocabulary, it is a matter of where the code lives and who reviews it. Two things follow that a project engagement does not give you. The client's team retains ownership of the architecture, and our developers can be scaled against the roadmap without anybody negotiating a change of scope.

The outcome

The repository records what the arrangement produced, which is the reason this case study can state a figure at all. Across the repository there are 1,258 commits from 17 distinct accounts between August 2023 and June 2026, of which 879, about seventy per cent, come from Sazinga addresses. Our developers worked alongside the client's own engineers and at least two other suppliers in the same codebase throughout, which is what a genuinely extended team looks like rather than an outsourced one. What the commit count does not measure is value, and it should not be read as though it did. It measures presence and continuity over nearly three years, which is the claim being made and the only one the evidence supports.

Most descriptions of an engagement like this are unverifiable by the reader. This one is not especially, but at least the shape of it is recorded somewhere other than our own account of it.

A roadmap is not a project

Optimus sells an automation platform for financial operations — reconciling payments, validating fees, preparing a close. The engineering problem underneath a product like that is continuous. There is no version that is finished; there is a roadmap that is more demanding in some quarters than others.

That pattern breaks the usual agency arrangement. A project engagement produces a deliverable, a handover and a body of code written by people who are then gone. For a product team, that code is a liability from the day it lands: written to someone else’s conventions, carrying assumptions about the rest of the system that nobody remaining can confirm.

The alternative is to add capacity to the team that already owns the product, and leave ownership exactly where it was.

What team extension means concretely

The word gets used loosely, so it is worth stating what it meant here in terms that can be checked.

Our developers commit into the client’s repository, not ours. They work on the same branches as the client’s own engineers. Their code is reviewed by the client’s reviewers, against the conventions already present in the codebase. There is no handover milestone because there is no boundary to hand across.

That arrangement is visible in the repository history. Across it there are 1,258 commits from 17 distinct accounts, between August 2023 and June 2026. Around 879 of those — roughly seventy per cent — come from Sazinga addresses, and the remainder from the client’s own people and at least two other supplier domains working in the same codebase at the same time.

The presence of the other suppliers is the part worth noticing. A team that can only function as the sole occupant of a repository is not an extension of anything.

What the numbers do and do not say

A commit count measures presence and continuity. It does not measure value, and anyone presenting it as though it did is inviting a question they cannot answer. Commits vary in size, in difficulty, and in whether they should have been necessary at all.

What it does support is the narrow claim being made: that developers were embedded in this product’s codebase, alongside the people who own it, continuously for nearly three years. That is a different assertion from “we delivered the platform”, and it is the one the evidence carries.

What this does not fix

Team extension puts capacity where it is needed without displacing ownership, which is what a product team should want. It does not substitute for having an engineering lead who owns the architecture on the client side — in fact it depends on one existing, because the conventions our developers work to have to come from somewhere.

Nor does it make a team cheaper per head. What it changes is how quickly capacity can move, and whether the code written this quarter is still comprehensible to the people maintaining it next year.