A dedicated software development team is easy to sell and hard to verify. The proposal names senior engineers, the sales call goes smoothly, and then you sign – and the people who show up in your repository three months later are not always the people you were shown. Most outsourcing engagements that disappoint do not fail on skill. They fail on the quiet gap between the team you were promised and the team you actually get.
If you are about to sign with a nearshore or outsourcing partner, the thing keeping you up is specific: rotated juniors billed as seniors, undisclosed subcontractors, and a delivery process you cannot see into. This piece is a set of tests for interrogating any vendor before the contract binds you – us included. A partner worth hiring will pass every one of them without flinching, and will tell you exactly how to check.
Why a dedicated software development team is hard to evaluate
Because the team that sells the contract is rarely the team that delivers it. Sales exists to close; delivery exists to ship. In a healthy vendor those two are tightly coupled, and in an unhealthy one they are strangers to each other. You are evaluating a proposal written by people you will never work with, about people you have not yet met.
First, qualify yourself out. If you need two contractors for a well-scoped three-week task, do not run this gauntlet – use a staffing marketplace, accept the churn, and move on. These tests are for the harder case: embedding a persistent team inside your product for a year or more, where continuity, code ownership, and knowing who is actually on the keyboard decide whether the engagement compounds or quietly rots.
The roster gap
The distance between the team named in the proposal and the team that shows up in your repository three months in. Senior, camera-ready engineers win the pitch; once the ink dries they rotate onto the next sale and quieter, cheaper people inherit your codebase. Every test in this article exists to measure the roster gap before you sign, not after.
Test one: ask for named engineers, then check their tenure
Ask for the actual people, by name, with links to their profiles – before you sign, not after. A vendor confident in the team it is selling will let you interview that team. A vendor that answers with anonymised CVs, badge counts, or “we will assign the right people at kickoff” is selling you a capacity, not a team, and the two are not the same thing.
Then check tenure, because seniority is measured in judgement, not years alone. Look at how long each engineer has been at the vendor, not just how long they have been writing code. Someone labelled “senior” who joined the company four months ago is a hire the vendor is still evaluating, placed on your account to find out whether they work out. Long tenure at one shop signals that the vendor keeps its people – which is the precondition for keeping them on your project.
A vendor confident in the team it is selling will let you interview the team it is selling.
Test two: find out whose process you will actually run
Ask whether the team joins your process or runs a parallel one behind a status report. This is the single fastest way to tell an embedded team from a black box. An embedded team works in your repository, attends your standup, opens pull requests your engineers review, and sits in your issue tracker where you can watch the work move. A black box takes a specification, disappears, and returns a demo on a schedule.
Conway’s law is the reason this matters more than it looks. A team that communicates with you only through a weekly status call will build software shaped like that call – coarse, late-binding, and full of assumptions nobody caught in time. A team wired into your daily process builds software that fits how your organisation actually works, because the two are in constant contact. When a vendor proposes its own separate ceremonies and a single point of contact, it is not offering you tidiness. It is offering you distance, and distance is where the roster gap hides.
Subcontracting belongs to this test too. Ask plainly whether the people on the account are the vendor’s own employees or contractors sourced from elsewhere. Undisclosed subcontracting is not automatically fatal, but a vendor that is evasive about who is on its payroll has already told you how transparent the engagement will be. For a fuller picture of what an embedded arrangement should include, our page on how a dedicated development team works spells out the model, and what you actually get and what you don’t is honest about its limits.
Test three: ask what happens when an engineer leaves
People leave – the question is whether their knowledge leaves with them. Ask the vendor to walk you through a real departure: how the handover was documented, how long the overlap lasted, and whether you got to interview the replacement before they joined. A vendor that treats rotation as a feature (“our flexible resourcing model”) is describing your knowledge draining out one resignation at a time.
Continuity is provable, and the proof is longevity. We embedded a team inside a regulated FinTech company, Self Learning Solutions, for eight years – long enough to grow from one workstream into three, spanning infrastructure, a SaaS product, and a UX redesign. That does not happen when people rotate; it happens when the same engineers hold context long enough for a client in a compliance-heavy industry to keep trusting them with it. The SLS engagement is the shape continuity actually takes.
Continuity applies to the work, not only the people. Our partnership with GroupM began with a single agency in 2018 and grew to serve agencies across 78 or more markets, and the encoded methodology at its core never broke – no full rebuilds were needed as it scaled. Ask a prospective partner for their equivalent: a system they have kept alive and growing for years, not a portfolio of greenfield launches they walked away from.
The questions to ask, and the answers that should worry you
Every test above collapses into one conversation before you sign. Put the questions in writing, and pay closest attention to the hesitation before the answer. Confident vendors answer these on the spot; the roster gap lives in the pauses.
Seven dimensions to interrogate before signing with a dedicated software development team.
| Dimension | Ask this | Warning sign |
|---|---|---|
| Seniority | Name the engineers on our account and share their profiles and tenure with you | Anonymised CVs, or names withheld until after the contract is signed |
| Continuity | Walk us through the last time an engineer left an account and how you handled it | Rotation is described as a flexibility feature rather than a risk to manage |
| Process | Will the team work in our repository, standup, and pull-request reviews | A parallel process, separate ceremonies, and a single weekly status call |
| Subcontracting | Are these your own employees or contractors sourced from elsewhere | Vague or shifting answers about who is actually on the payroll |
| Code quality | Show us your review process, CI setup, or a repository we can inspect | Quality is asserted in the deck but never demonstrated in practice |
| Exit | Put knowledge transfer, code ownership, and documentation in the contract | Exit terms are unwritten, or leaving means losing access to your own work |
| Track record | Name a client you kept for years and one whose team you handed off to | Only short greenfield logos, no long engagements you can call to verify |
Do not expect a perfect scorecard. A vendor that answers every line with an unqualified yes and never pushes back is telling you it will interpret your specification too literally and build exactly the wrong thing without ever raising a hand. The partner you want pushes back on some of these and explains why. That is judgement.
Test four: make them show you the exit
Ask how you leave before you ask how you start. An honest partner can describe, in concrete terms, how you would take the work in-house: who owns the code, where the documentation lives, how a knowledge transfer to your own engineers would run, and how long it would take. A partner who cannot describe the exit is quietly relying on your inability to leave.
The strongest evidence a partner will not trap you is that they have already made themselves unnecessary at least once. We built a video workforce-management platform for TiVO between 2016 and 2020, and then handed it to TiVO’s own team, who owned and scaled it independently for the six years that followed – reaching 18 markets and 66 million tasks a year without us. A vendor that has done that has proven the exit is real, because they have walked through it. The VOD workforce-management build is what a clean handoff looks like.
The exit clause
Write the handoff into the contract, not the goodwill. Name who owns the source code, where documentation is kept current, and what a transfer to your own engineers would require. A partner confident in the work will sign this without negotiation, because they expect to earn the next year rather than trap you into it.
Now run the checklist on us
These four tests reframe the decision. Evaluating a dedicated software development team is not about comparing hourly rates or counting certifications; it is about closing the roster gap before it becomes your problem to manage. The vendors worth signing with are the ones that hand you the questions and dare you to ask them.
So use this on us. Ask for the named engineers and their tenure, ask to see how we work inside your repository, ask what happened when someone left an account, and ask us to write the exit into the contract. We have kept a team inside a regulated FinTech for eight years and handed a platform back to its owners cleanly – both are true, and both are checkable. Bring us the checklist and put us through it.