How to choose the right external development team

The right external development team is one that scopes your project honestly, staffs it with senior engineers who write the code themselves, communicates in plain terms when something is going wrong, and is willing to say no to work that will not serve you. Everything else is a variation on those four things.

Hiring an outside team is a decision with serious consequences. The wrong partner costs you time and progress you cannot get back. Over the years we have been on both sides of this decision: as the team being evaluated, and as advisors to founders and engineering leaders deciding who to trust with a product that matters. The pattern is consistent. The teams that pick well do not run a longer process. They ask more precise questions and they pay closer attention to how the answers are given. Here are five practical checks to run before you sign anything.

1. Ask who actually writes the code

Many firms promise you a senior team during the pitch, then staff the project with whoever is available. This is the oldest problem in the industry. The people on the sales call are often the strongest engineers the company has, and they are the ones least likely to work on your code once the contract is signed. Ask directly: who are the individual engineers on this project, what have they delivered before, and will they still be on the team in month three? A partner that cannot answer this clearly is giving you a warning.

The best answer is specific and honest enough to be uncomfortable. It names people. It says what those people built, where, and what went wrong along the way. In our work the strongest engagements start with the same engineers who scoped the project also writing the first commits, because the context is lost when work passes to another team. When a firm reacts to this question by talking about its "process" or its "bench" (its engineers who are not on a project) instead of naming humans, that is a warning sign. People write the code, so ask about people.

2. Look at how they scope the first two weeks

A team that understands your problem will propose a short, concrete first phase: a specific piece of working software, not a slide deck. If the first deliverable they propose is a strategy document, be cautious. You are hiring builders, not consultants.

There is a simple reason this test works. Planning a real first piece of work forces a team to make decisions early, and decisions are where you learn how someone thinks. A builder will pick the riskiest unknown in your product and propose to work on it first, because getting that wrong late is expensive. A team that starts with discovery workshops and a phased roadmap is often protecting itself from committing to anything it can be measured against. Ask what they would build in the first two weeks and why that piece and not another. The answer tells you whether they see your product as a set of problems to solve or a set of hours to bill.

3. Check how they communicate under pressure

Every project has problems. The question is whether your partner tells you early, in plain language, with options, or whether you find out three weeks later that a deadline was missed. Ask a reference client one direct question: "Did they ever miss something and how did they handle telling you?"

Listen carefully to how the reference answers. A reference that says the team was perfect and nothing ever went wrong is either not being candid or has not worked with them long enough to matter. The useful answer describes a real moment of trouble and a team that reported it fast, explained the tradeoff in plain terms, and came with a recommendation rather than no plan at all. Weak teams share bad news slowly and strong teams share it quickly. The teams we trust most are the ones that tell us about a hard problem as soon as they know it, before it grows into a crisis. You want the same from anyone you hire.

4. Confirm you keep the code and the decisions

You should own the code, the architecture decisions, and the documentation, with no exceptions. If a vendor is vague about who owns the intellectual property or keeps critical knowledge only in their own tools and memories, you are building a dependency, not a product.

Ownership is a legal question and also a practical one. Get it in writing that the intellectual property is yours, but then go one step further and ask how the work will be handed over if you stop working together. Where is the code stored? Who has access to the accounts and the infrastructure? Is the reasoning behind the major architecture choices written down somewhere you can read, or does only one engineer know it? A good partner builds so that you could take over tomorrow, even though the whole point of the relationship is that you would rather not have to. That is the difference between a team that is confident in the value of the work and one that is protecting its position without saying so.

5. Match the engagement model to your actual need

A team joining your existing engineering organization needs to adopt your tools and your regular meetings and habits, not impose new ones. A team building something from nothing needs to own strategy, design, and engineering together. Ask which model they are proposing and whether it matches what you actually asked for.

This is where a lot of otherwise good decisions go wrong. A founder with no engineering team who needs a product built from scratch does not need two contractors added to a codebase that does not exist yet. A company with a strong internal team and a specific need for more engineers does not need an outside group trying to redesign how it works. If you have people and a system, staff augmentation means bringing in senior engineers who fit into your process and raise the level of the team around them. If you have an idea and a deadline, a full product build means handing off strategy, design, and engineering to one team that owns the outcome. The mistake is buying the model a firm prefers to sell rather than the one your situation calls for. A partner worth hiring will tell you when the model you asked for is the wrong one.

None of these checks require special expertise. They require asking direct questions and paying attention to how clearly the answers come back. The teams that pass are usually the ones that make you feel uncomfortable during the conversation, because they answer plainly and expect you to check that they keep their word.

How this works across engagement types

These checks apply whether you are looking to add one or two senior engineers through staff augmentation or hand off an entire product through a full product build. The engagement model changes what "the right team" looks like day to day, but the same four questions, who writes the code, how they scope the first two weeks, how they communicate under pressure, and who owns the output, still separate a real partner from a good sales pitch.

Add one question to your list that did not exist two years ago: what share of this team's code is written by AI, and who reads it before it reaches our branch. Almost every supplier is now generating some of what they hand you, and the ones who are unwilling to answer are the ones to worry about. Our own answer is that all of it is generated and all of it is read by a named engineer who is responsible for it. What you want is an exact number and a named human, in either order. A team that will not give you both is asking you to trust a process they have not thought through.

More detail on each part of this decision

Four related guides explain specific pieces of this decision in more depth:

• Software development partner vs. vendor: the difference between a team that builds what you ask for and one that tells you when the ask is wrong.
• Fractional CTO vs. software development agency: whether your gap is technical leadership, execution, or both.
• Software consulting firm vs. development agency: the difference between paying for a recommendation and paying for delivered code.
• Red flags when hiring a software development agency: the specific warning signs worth checking before you sign anything.
• Development agency vs. freelance marketplace: what changes when you buy access to individual freelancers instead of a team accountable for the outcome.

If you are evaluating a partner for a VC or PE portfolio company specifically, technical due diligence for VC portfolio companies covers the version of this review built for an investment decision rather than a hiring decision.

Related guide: How to choose a software development partner.

If you are choosing between suppliers right now rather than reading up on the models, the side-by-side version of this is Reveneau vs a traditional software development agency, which lays the options out in a table with the sources labelled.