How to choose an IT vendor without the project slipping

A real case first: a client was six sprints into a $90,000 build and every report was green. Graded against the written acceptance criteria, three of the six sprints were only partially delivered. The vendor had been demoing the happy path and deferring error handling, permissions and data migration to a phase that did not exist in the contract. It was caught at sprint six and renegotiated at no cost. Most of what follows is about catching it before you sign.

In short: price and portfolio are the two least predictive indicators of whether a project will succeed. What predicts is how a vendor reacts when something goes wrong — and you can test that before signing, with four specific questions. The best vendor isn't the one who says yes to everything: it's the one who tells you no, with reasons, during the sales process.

Why portfolios mislead

A portfolio shows delivered projects. It doesn't show abandoned ones, actual timelines, or how many times the client had to chase. Two vendors with comparable work can behave completely differently under pressure.

Ask instead for a reference on a project that went badly, and what was done about it. An experienced vendor has one and can talk about it. One who claims never to have had a difficult project is telling you either that they're inexperienced or that they're not being straight with you.

The four questions that discriminate

• "What happens if we change our mind about a feature mid-project?" A good answer describes a process: impact costed in time and budget, an explicit decision, a written record. A bad answer is "no problem, we'll sort it out" — that's the promise that becomes a surprise invoice.
• "Who will actually work on this, and how many other projects are they on?" You often meet the strongest profile in the pitch and a different one in delivery. Ask for names, and ask in writing.
• "Who owns the code, and how do we access it?" Without access to the source and the technical accounts, you aren't managing your vendor — you depend on them. This is the most expensive thing to fix after signing.
• "How much of our time do you need, in days, during the project?" A serious vendor has a number. One who says "very little" either never measured, or is laying the ground to blame your availability later.

The most reliable signal

A good vendor contradicts you before signing. They tell you your scope is too large for the budget, your deadline isn't achievable, or that a feature you asked for won't be used by anyone. It's uncomfortable in the meeting and profitable six months later.

A vendor who accepts everything without discussion hasn't assessed your project — they've assessed your willingness to buy.

What to put in writing

• The scope, with its explicit exclusions
• Acceptance criteria, defined before development starts
• Expected response times, in both directions
• Code ownership and handover of access
• What happens if the engagement ends early

That last point is the one everyone avoids discussing because it feels awkward. It's also the one you need at precisely the moment nobody is in the mood to negotiate.

A vendor scorecard you can use today

Score each vendor from 0 (no answer) to 2 (specific, written answer) on the eight lines below. A vendor under 10 out of 16 has not earned your signature yet.

Question	0	1	2
Describes a project that went badly and what they did	Claims none	Vague story	Specific, with the fix
Change-request process	"No problem"	Verbal process	Costed in time and budget, in writing
Named people on your project	Unknown	Roles only	Names and allocation, in writing
Code ownership and access	Unclear	"Yours at the end"	Repository and accounts in your name from day one
Your time needed (days)	"Very little"	A guess	A number per phase
Challenged your scope or budget before signing	Never	Mildly	Told you what to cut and why
Acceptance criteria	Defined at the end	Defined per milestone	Written before development
Exit terms	Not discussed	Notice period only	Handover, documentation, access transfer

What goes wrong when you skip it

The $90,000 case above would have been flagged by the scorecard before signing: acceptance criteria "defined per milestone" scores 1, and no exit terms scores 0. A second pattern: two quotes for the same mobile app, $18,000 and $47,000, where the cheaper vendor had scoped no offline mode, no role management and no admin back-office. Comparable quotes need a comparable document, which is why a PRD comes before vendor selection, not after.

Questions about contracts, not just competence

• Is payment tied to accepted deliverables or to calendar time?
• Who pays for defects found after acceptance, and for how long?
• Does the contract say the vendor must hand over source, documentation and credentials on request, not only at the end?

Check the vendor's security posture, not just the price

Ask whether the vendor builds against a recognised baseline such as the OWASP Application Security Verification Standard, and whether the company holds ISO/IEC 27001 certification. Neither guarantees good work, and a small studio can build securely without the certificate. But a vendor who cannot say how they handle authentication, secrets and tenant isolation has not thought about it. For how requirements should be phrased so they can be checked, see ISO/IEC/IEEE 29148.

When you cannot judge the answers yourself

If you are non-technical, you can still use the scorecard, because it grades specificity, not technology. For what you cannot assess, an independent reviewer on your side is cheaper than one change request. See Build Oversight for sprint-by-sprint grading, or the Delivery Risk Audit if a project is already running and you want to know where it stands. For choosing between a vendor, a fractional CTO and an in-house hire, read this decision guide.