How to choose a development vendor: what to check before you sign

Short answer: a development vendor is judged on the people who will work on your project and on comparable projects you can verify. The portfolio and the pitch deck are prepared by different people and say little about how the team works. The most reliable check is a small paid first stage with a result you can inspect. A few weeks show how the vendor asks questions, holds dates and hands work over, and walking away at that point is cheap.

Who will actually do the work

The first meeting often brings the founder and a salesperson, while the project is later run by other people. Ask outright who will run it on their side, who the architect is and how many developers there will be. Ask for the project lead to be at the second meeting.

Find out how many projects those people are running in parallel. A lead with five of them answers questions the next day.

Subcontracting is a separate question. Plenty of studios send part of the work out, which is fine as long as you know about it and the contract accounts for it.

Comparable projects you can verify

Comparable means a comparable problem: the same integrations, the same class of system, a similar scope. A handsome retail website says nothing about whether the vendor can handle an exchange with your accounting system and access rights for three roles.

Ask to see a working system; screenshots are not enough to check anything. If the project is under an NDA, the vendor can walk you through it anonymised, or describe what went wrong and how they fixed it. How specific that account is tells you whether these people built it themselves.

A call with a past client

Ask for a contact at a client with a comparable project and put three questions to them. Did the project hold its schedule and budget, and if not, how did the vendor tell them. What happened after launch. Would they work with them again.

A refusal to hand over a contact is not a bad sign in itself: clients do not always agree to it. If there is no contact at all, though, it is worth asking why.

The first stage as the test

Instead of one large contract, agree a first stage of a few weeks: a process review and a prototype, one integration as a pilot, the first role in the system. The stage needs a result you can inspect and a price you would not mind losing.

That stage shows more than every meeting combined. Whether the vendor asks about your process or proposes a solution straight away. Whether they warn you about a slipping date in advance. How they hand work over and how they take criticism. How to accept such a stage is covered in accepting work from a vendor stage by stage.

When to walk away

A price before the questions. An exact figure for a system the vendor knows two paragraphs about can only be a guess. A range with an explanation of what drives it is the honest answer.

No pushback at all. The vendor agrees with everything you propose. A good one will say at least once that part of the scope is expensive and could wait, or that an off-the-shelf product would cover it.

The code and the accounts stay with the vendor. If the contract has no handover of the code, and servers and accounts are registered to the vendor, you depend on them for years. What to write down to avoid that is in what to put in a development contract.

Comparing proposals

Comparing bottom-line totals is useless when the estimates are broken down differently and one of them has no data migration in it while another has no support. Reduce them to the same lines and compare development plus the first years of support together. How to take an estimate apart line by line is in how to check a development estimate.

Common questions

Is a tender worth running? For development, a tender decided on price usually picks whoever underestimated the scope hardest. Better to shortlist two or three vendors on comparable projects and compare them on a first stage, or on a detailed estimate.

Freelancer or studio? A freelancer suits a small piece of work that somebody else will be able to maintain afterwards. For a system a whole department depends on, what matters is that the project does not rest on one person.

Should there be a test assignment? Good vendors are reluctant to do unpaid test work, and it says little about how they behave inside a project. A paid first stage is more use to both sides.

The rule

Choose a vendor on the people and on comparable projects, and test them on a first stage you would not mind paying for even if you go on with somebody else.