Dedicated team or development retainer: which one your product needs

If you have someone senior on your side who will run the developers (set priorities, run sprints, read the pull requests) you want a dedicated team. If you do not, and nobody is going to, you want a retainer. That is the whole decision. Everything else on this page is what happens when a company picks the wrong one, and how to tell early.

The two models, one sentence each

Dedicated development team: your management, our developers. We supply people who fit your stack and stay. You decide what gets built and in what order, and you review the work. The developers are in your Slack and your repository, and they report to your lead.

Software development retainer: our management, your product. We own the architecture, the roadmap, delivery and the on-call. You own the business and the outcome. You still see everything, you still say no, but the decisions nobody else on your side is placed to make (what to refactor, when to upgrade, what not to build) are ours to make and defend.

Same developers. Same rate per person. The thing that changes is who is accountable when a decision turns out to be wrong.

Why the industry blurs them, and why it costs you

Most vendors sell "dedicated developers" and "managed teams" as tiers on a pricing page, with the managed one costing more. That framing hides the actual difference (who owns the decisions) behind a price difference, and it lets a buyer with no technical lead pick the cheaper tier and discover in month four that nobody has been steering.

We price both the same on purpose: the same person costs the same in either model. If you pay the same either way, the only reason to pick one is that it is the right shape for you. That is the conversation we want to have on the first call, not a tier to upsell.

Signs you picked the dedicated team but needed the retainer

• The developers keep asking "what should we do next?" and the answer takes a week to arrive.
• Pull requests sit unreviewed for days, because nobody on your side reads code.
• The backlog is a list of features. There is no line in it for the upgrade that should have happened in March.
• The 2am incident is handled by whoever notices, and the post-mortem is a Slack thread.
• You are paying for a senior developer's month and getting a senior developer's guesses.

None of these mean the developers are bad. They mean the seat above them is empty. Filling it is what a retainer is.

Signs you picked the retainer but needed the team

• You have a CTO, and they are frustrated at not owning the roadmap.
• Every architectural decision comes back with "why did you do it that way?" from someone who would have done it differently, and could have.
• You want to interview and choose each developer individually, and the retainer's "we staff it" feels like a loss of control.
• Your product is early enough that the decisions are the business, and you want them in-house.

In that case a dedicated team gives your CTO the hands without taking the wheel. Same people, reporting line moved.

What stays the same either way

Because this is where vendors differ most, and where we do not:

• Everything in your accounts. Repository under your organisation, hosting and services in your name, our people added as members. If we part ways, nothing is handed over because nothing was ever ours. The full list of accounts and who should own them.
• Interviews before anyone starts. On the team model you interview each developer. On the retainer you interview the engineering lead who will own your system, and can meet anyone they bring on.
• One published rate per person, set by stack and seniority. Not a tier, not a bundle. Three to five people is the typical size for either.
• A month's notice both ways. The team has no minimum term. The retainer starts with three months, because owning the architecture takes that long to earn.

How the five retainers we run actually started

All five are under NDA, so shapes rather than names. Three of them started as dedicated-team engagements (a founder or a product lead running our developers) and moved to a retainer when that person's job changed. One founder went from building the product to selling it, and the engineering seat emptied. One product lead left and was not replaced. In each case the developers stayed. The reporting line moved to us, and the monthly review replaced the sprint they used to run.

The other two started as retainers from day one: a business owner with a product past its MVP and no technical hire, who did not want to make one. The oldest of the five predates the company's current form. That is the receipt for the model: not that it is better, but that it lasts.

A checklist for the first call

Answer these five and the model picks itself:

1. Who on your side would read a pull request this week? If nobody: retainer.
2. Who decides what gets built next quarter: a person, or a spreadsheet nobody owns? If nobody: retainer.
3. Do you want to interview each developer, or the person who will own the system? Each developer: team.
4. Is the engineering decision the business decision right now? If yes: team, and keep it close.
5. If the product breaks at 2am, whose phone rings? If you do not know: retainer.

If your answers split, start with the team and keep the retainer in reach. Moving between them is a conversation, not a migration: the people, the code and the accounts do not change.

*Related: Dedicated development team in India · Software development retainer · What a dedicated Flutter developer costs*