Team Extension/Dedicated Team
A cross-functional team — delivery lead, engineers, design, QA — working for one client on one product. Not a fixed-scope project, and not a single engineer placed into an existing team.
A product area has no owner. The in-house team is at capacity, and standing up a whole function — lead, engineers, QA — takes quarters of recruiting. Contractors close the gap for a while, then leave with the reasoning behind every decision they made.
EngageRocket
Designers and engineers from Agile Labs built the core of EngageRocket’s platform as one team inside the client. The launch raised a US$3 million round, and the platform runs in 14 countries.
Read the EngageRocket story →
The client owns product direction — priorities, acceptance criteria, release decisions. The team owns sprint planning, technical decisions and release readiness; we own keeping the team whole.
The first conversation settles one question: capacity the client manages — a Senior Engineer under their direction, or an outcome stream we manage. Capacity is a single senior engineer under the client’s direction; the outcome stream is a Dedicated Team.
A named delivery lead is the structural difference: one person answerable for the team, one contact for the client. A product owner emailing developers directly means accountability has already fragmented, and the monthly steering conversation is where that gets reset.
Reporting is five delivery measures — lead time, deployment frequency, recovery time, change-fail rate, rework rate — tracked as trends on this product only, and the research behind them warns against setting them as targets, comparing teams, or reading them per person (DORA, 2024). We do not report story points and we do not monitor individuals.
Sized for the work rather than from a template, seniority front-loaded where the architecture is still forming. The client interviews the named people; the delivery lead is appointed.
Week one, access and context; week two, the working agreement and the definition of done; a change in production by week three or four.
Working software demonstrated every week and planning with the client’s product owner, then a monthly steering conversation at sponsor level on trends, risks and decisions needed.
Terms for adding or removing a seat are in the engagement from day one, work in progress assigns cleanly to the client, and redeployment on a scale-down is our problem.
Complete code and documentation already in the client’s systems, credentials and admin transferred, knowledge-transfer sessions recorded, and every provider-side access revoked.
The team is the product, so keeping it whole is the commitment. What follows is in the engagement from the first sprint rather than negotiated at the end.
If an engineer leaves mid-sprint, we fill the gap. The client does not reopen a role, sit through a recruitment cycle or absorb the delay — owning team composition and transitions is what separates this from capacity the client manages.
Every critical area has at least two people who can cover it, and ownership rotates inside a stable team instead of people rotating off it. Decisions are written down so a new member inherits the reasoning, not just the code.
What the client receives at handover goes into the engagement before the first sprint, not into a negotiation at the end. A team that has agreed how it leaves is easier to trust while it stays.
A short conversation with the engineers who would do the work — and a straight answer when a single senior engineer is the better buy.