VANDANAlabs

For anyone about to hire a development team

How to evaluate a software development vendor

A buyer's guide to choosing a development partner: the questions that actually separate vendors, the red flags worth walking away from, and when you should not hire an agency at all.

· 9 min read

Hiring a development team is a decision made with bad information. You are buying something you cannot inspect, from people whose work you cannot evaluate, on the basis of claims you cannot verify. The websites all say the same things. The portfolios are all screenshots of things that worked.

This is a guide to getting past that. We build software for a living, so we are not a neutral party — but everything below is what we would want a buyer to ask us, and several of the answers cost us work. Where an honest answer points away from hiring a firm like ours, it says so.

Before you talk to anyone

Most bad vendor decisions are made before the first call, because the buyer has not decided what they are actually buying. Three things are worth settling first.

Is this a project or a capability?

A project has an end. A capability is something your business will keep needing. If you are buying a capability — software that will change every month for the next five years — then long term, hiring is cheaper than any agency, including us. Agencies are the right answer for projects, for capacity you need now rather than in six months, and for skills you need once rather than permanently.

The failure mode is hiring an agency for a capability, then discovering three years in that your core system is understood only by a company you do not employ.

What happens if you do nothing?

If the honest answer is "not much", you have a nice-to-have, and nice-to-haves die halfway through when attention moves elsewhere — usually after you have spent half the budget. The projects that finish are the ones where somebody is genuinely blocked.

Who can approve a decision?

Name that person before you start. Projects rarely fail for technical reasons; they stall because nobody on the client side could make a call without convening four people, and a two-week question became a two-month one. If the answer is "a committee", build that into the timeline you expect and the price you will pay.

The five questions that actually separate vendors

Generic questions get generic answers. Every firm says they are experienced, communicative, and quality-focused. These five are harder to answer smoothly, and the shape of the answer tells you more than the content.

1. Who specifically will write the code?

Not "our team" — names, and whether you will meet them before signing. In a lot of firms the people who run the sales process are not the people who do the work, and the gap between the two is where disappointment lives. Ask whether the person on this call will be on the project. Ask what else they are working on and how many projects they carry at once.

2. What happens if we want to leave?

Ask who owns the code, who owns the cloud accounts, and how long it would take you to remove their access. The answers should be: you, you, and about five minutes.

Watch for proprietary frameworks, platforms you keep licensing after the project ends, infrastructure in the vendor's accounts, and code delivered as a licence rather than an assignment of ownership. Each of those is a switching cost, and switching costs are how a vendor keeps a client who wants to leave. Get the ownership terms in writing before you sign, not at handover.

3. What is the price, and what happens when the scope changes?

The second half matters more than the first. Scope always changes. What separates vendors is whether the change is priced before the work happens or arrives on an invoice afterwards.

Time-and-materials is not automatically worse than fixed price — but it transfers the risk of a bad estimate from the vendor to you, and you should know that is what you are agreeing to. If a firm quotes hourly, ask what happens if it takes twice as long as they estimated. If they quote fixed, ask what happens if you change your mind in week six.

4. Can I speak to a client doing something similar?

Case studies are written by the vendor. Reference calls are not. A firm that cannot produce a single client willing to spend twenty minutes on the phone is telling you something, and confidentiality only explains so much — plenty of clients under NDA will still take a call.

On the call, skip "were you happy". Ask what went wrong and how it was handled. Every project has a bad month; what you are testing is what the vendor did during it.

5. What are you bad at?

The most useful question in the set, because it is almost impossible to answer well without being honest. A firm that claims no weaknesses is either inexperienced or managing you. Good answers are specific and structural: team too small for parallel workstreams, no certification a regulated buyer needs, no on-site presence, weak in a particular domain.

A vendor who tells you unprompted that you should not hire them for something has just given you a reason to trust what they say about everything else.

Red flags

  • A quote produced without asking what happens if the project fails. If nobody asked about the stakes, nobody scoped for them.
  • Estimates that arrive suspiciously fast and suspiciously round. A same-day fixed price on a complex integration is a number, not an estimate.
  • Pressure to sign before a scope document exists. Scope written after the contract is scope written by the party holding the contract.
  • "We'll figure that out during the build." Sometimes true for genuinely novel work. Usually it means nobody has thought about it.
  • No named engineers before signing. If you cannot meet the people, you are buying an allocation, not a team.
  • Certifications claimed but not evidenced. Ask for the report, not the badge. This one is checkable in about a minute.
  • A portfolio of screenshots with no outcomes. Anyone can show a nice interface. Ask what changed for the business.

When you should not hire an agency at all

Three cases where the honest answer is to spend nothing with a firm like ours.

  1. 01You have not validated the idea. If you do not yet know whether anyone wants this, no-code tools and a spreadsheet will tell you for a fraction of the cost. Validate first, then build properly. Building first is the most expensive way to learn that nobody needed it.
  2. 02The work is genuinely continuous and central. If this software is your business and it will change forever, hire. Recruiting takes three to six months and is expensive, but a permanent need met by a temporary supplier gets more expensive every year.
  3. 03Your requirements are precise and you have a technical reviewer. If the specification is unambiguous and someone in-house can review the output, a good freelancer or offshore team will do it for meaningfully less. What you are paying an agency for is judgement about what to build and the ability to hold the architecture — if you already have that, you are paying twice.

How to run the first call

Thirty minutes is enough to disqualify most firms. Spend the first ten describing the problem rather than the solution you have in mind — the vendors worth hiring will interrupt with questions about constraints, and the ones who take the brief at face value and start describing their process are telling you how the project will go.

Then ask the five questions above. Do not spread them over three calls; ask them in one, because the value is partly in watching someone answer five uncomfortable questions in a row.

You are not trying to find the vendor with the best answers. You are trying to find the one whose answers are specific, consistent under follow-up, and occasionally against their own interest.

A note on where we stand

We wrote this because it is the evaluation we would want a client to run on us, and because a buyer who asks these questions makes a better client — the projects that go well are the ones where the scope was argued about honestly before anyone signed anything.

If you want to run it on us: our rates and full price bands are published, our contract and IP terms are on the trust page including what we are not certified for, and we will connect you with a client doing comparable work before you commit to anything. Those are answers to three of the five questions above. The other two are worth asking us on a call.

Run this on us

Our price bands are published, our contract and IP terms are written down including what we are not certified for, and we will connect you with a client doing comparable work before you commit to anything.

← All insights

Want a straight answer on your project?

Thirty minutes, no deck. We'll tell you how we'd approach it — or that you shouldn't build it, if that's what we think.

We reply to every serious enquiry within one business day