How to vet a development team: 8 practical methods

Everyone's portfolio looks good. The slides, the case studies on the website, the client logos.

The problem is that none of it proves the team can deliver your project. A portfolio shows finished work; it does not say how the work went — how far it slipped, whether it went over budget, or whether the client would hire them again.

Here are eight practical methods. They tell you far more than a portfolio does.

1. Speak to a client directly

The strongest method, and the one most often skipped.

Ask for the contact details of a client in your industry and call them. Ask three questions:

Did the project finish on schedule? If not, by how much and why.

Did the budget hold? If it did not, was that additional work or an initial misjudgement.

How were problems handled when they came up? This is the important one. Problems arise on every project; the difference lies in how they are handled.

"Not possible, confidentiality" tells you something. A satisfied client agrees to talk.

2. See a live system

Not a demo — a system with real users on it.

Demos always look good: the data is clean, nothing fails, every button works. A live system shows the real state — how much data it holds, how fast it is, whether the interface is workable.

If you can, watch an employee using it. How a storekeeper or a salesperson works with a system tells you a great deal.

3. Meet the person who writes the code

The meeting usually involves a salesperson or a director. Someone else does the work.

Ask to meet the technical lead or senior engineer. Check two things in that meeting:

Do they ask about your business? A good engineer asks about the process, not the technology. "How is your inventory tracked", "who signs this off" — those are the right questions.

Can they explain something complex simply? If the answers are full of jargon and you understand none of it, the project will run the same way.

4. Ask about their difficult projects

Ask directly: "Tell me about the last time a project went badly."

A good team gives a specific example and explains what they changed afterwards. A team that has never had a problem is either inexperienced or not telling you everything.

What to listen for: whether they place the blame entirely on the client or acknowledge their own share.

5. Establish the team composition

• How many engineers will be on the project and are they committed elsewhere
• Is there a project manager and how many projects do they run in parallel
• Is testing a separate role or do developers check their own work
• Is the team permanent or assembled for each project
• What is the turnover — how many people left in the past year

The last question is delicate but fair to ask. High turnover means people changing mid-project, and that always affects the timeline.

6. Look at their documents

Before any commitment, ask for two documents: a sample scope and their contract template.

Both are revealing. A detailed, specific sample scope means the team works systematically. A page of general description means the project will run the same way.

Does the contract include acceptance criteria, a change process and a code ownership clause? If not, the team has not thought about these questions.

7. Test with a small piece of work

The most reliable check is seeing it in practice.

Before a $70,000 project, start with a $3,500 discovery stage. In two weeks you will see:

After that stage you can change teams and the document stays with you. It is the cheapest test available.

8. Count the warning signs

Two of these mean caution. Three mean look elsewhere.

"We can do everything." That means no specialisation. Nobody is strong in every industry and every technology at once.

A price without a scope. An exact figure at the first meeting is a guess. It will either rise later or the scope will shrink.

No client reference. Confidentiality is sometimes genuine, but if not a single client can be found, that raises a question.

Agreeing too quickly. If every requirement gets "yes, we'll add that", nobody is thinking about scope. A good team asks questions and sometimes says "you don't need that".

Competing on price alone. Forty per cent below the competition — ask what has been removed from the scope.

A one-page contract. That is a sign of disorder, not simplicity.

How to compare

Pick three teams and apply the same process to each:

In summary

A portfolio shows what a team can build. References and a discovery stage show how they work — and that is what determines how the project ends.

Practical steps:

1. Speak to at least two clients directly — free and the most accurate signal
2. Meet the person who writes the code, not the person who sells
3. Ask for a sample scope and contract template up front
4. Test the team on a discovery stage before committing to the full project
5. Count the warning signs: two is caution, three is a stop signal