Evaluating a Digital Vendor: The Questions That Actually Matter

By the time you are choosing between three shortlisted vendors, they all have decent portfolios, plausible pricing, and a persuasive pitch. That is why you are stuck.

The differences that will actually matter over the next twelve months are not on the pitch deck. They come out when you ask the questions the vendor was not expecting.

Some of what follows works against our own short-term interest to publish. We think that is fine.

Ask about their process in specifics, not slogans

Every agency has an "agile process" or a "proven methodology" on its website. Neither phrase tells you anything.

Ask instead: "Walk me through the last two weeks on a live project you are currently running." What meetings actually happened. Who was in them. What decisions were made and where they were written down. What the client saw and when.

A partner with a real process describes something concrete and slightly unglamorous — Monday planning, Wednesday demo, a shared board that reflects reality, a written weekly note to the client. A partner without one drifts back into abstractions about "collaboration" and "iteration".

Follow up with: "How often will I see working software, not screenshots?" The right answer is weekly, from an early week, on a URL you can click. Anything less frequent means the first real look is late, and late looks reveal expensive problems.

Ask what went wrong on their last project

Everyone has a project that did not go to plan. The useful signal is what they say about it.

The answer to worry about is one where every cause was external — the client was difficult, the timeline was unrealistic, the third-party API changed. This may all be true and it still means the vendor learned nothing they can apply to your project.

The answer that should reassure you names their own contribution specifically. "We underestimated the data migration and did not flag it early enough. Now we do a two-day discovery on any migration before we quote." That is a team that has a mechanism for improving. The other one will make the same mistake on your work.

Ask also: "What is a project you turned down, and why?" A vendor who turns nothing down either has no work or no judgement. The examples they give tell you what they know they are bad at, which is useful information you cannot get any other way.

Ask about code ownership from day one

The right answer to "who owns the code" is immediate and unambiguous: you do, from the first commit, in a repository on infrastructure you control.

Wrong answers come in several flavours. "You own it on final payment" means the code is hostage to any dispute. "We deliver it as a zip at the end" means you have no history, no ability to see who wrote what, and no working relationship with your own codebase. "It runs on our platform and we manage it for you" means switching cost is deliberately high.

Push further: "Can I add a developer of my own to the repository next week if I want to?" A partner who is comfortable with this is confident in their work and honest about the relationship. A partner who resists is telling you something.

"If we hire a technical person in six months who has never seen this project, how long until they can deploy a change?" The answer forces the vendor to think about documentation, environment setup, and readability — the things that matter for years and get skipped in month one.

Ask about handover before you sign

Handover is easy to promise and easy to skip, because by the time it matters the project is finishing and everyone is tired.

Get specific in the contract. What documentation will exist and where. Who has which credentials and how they transfer. What the deployment process looks like without the vendor in the room. What happens to work-in-progress if either side ends the engagement early.

The question that reveals most is: "Show me a handover document from a previous project." Not a template — a real one, with the client name redacted. If they cannot show you one, they have not done it before, whatever the sales page says.

Ask about hidden costs

The price on the proposal is not the price you will pay. Some of the cost is genuinely unknowable at quoting time, but you should know where the surprises usually come from.

Ask directly: "What are the three things clients most commonly need to add budget for after the project starts?" An honest partner has a ready list — content entry, data migration, third-party licences, translation, extra design rounds, integration with a system you had not mentioned.

Follow with: "What is your change request process, and what does a typical one cost?" A vendor with a fair process shows you how requests are estimated and when a change is small enough to absorb. A vendor whose change process is opaque is planning to recover margin through it.

Ask about hosting, monitoring, backups, and post-launch support separately. A proposal that hides them is quoting for half the project.

Ask what happens when the project changes shape

Nearly every project of any size changes direction at least once. The question is whether the vendor's process is built for it.

Try: "In month two, our board decides they want the thing to work differently in a way that affects a third of what has been built. What happens in the following week?"

A useful answer describes a process: which meeting happens first, who re-estimates, how the trade-off between scope, time, and cost is presented. A useless answer is "we are flexible". Everyone says they are flexible. Almost no one has a mechanism for it.

Ask also: "What have you done when a client asked for something you thought was a bad idea?" A vendor who has never pushed back will build whatever you ask for even when they can see it is wrong, and the finished thing will be your fault, not theirs.

The gut checks that matter

A few smaller signals worth attending to.

Who is in the room in the pitch, and who will actually do the work? If the senior people you meet vanish after signing, you have bought a different service from the one you evaluated. The contract should name the people you are paying for.

How do they treat questions they do not know the answer to? "I don't know, I will find out and get back to you today" is the answer of a mature team. Confident guessing is the answer of a team that will confidently guess later, when the stakes are higher.

How much of the meeting is them talking? A vendor who has not asked you five substantive questions about your business by the end of the first meeting is selling from a template.

Do they tell you anything you did not want to hear? A pitch with no pushback is a pitch designed to win, not to work. The vendors who will serve you best are the ones who tell you which parts of your brief they would change, and why.

What to do with the answers

You are not looking for a vendor who scores perfectly on all of this. You are looking for one who answers honestly, including where the answer is imperfect.

The partner worth choosing is usually the one who was hardest to sit through the meeting with — because they slowed you down, made you defend your assumptions, and told you something inconvenient about your own project.

The one who agreed with everything and promised the shortest timeline is almost never the right one, and you already know it.

If you are working through a shortlist right now and want an outside read on the proposals, we are happy to look — including when the honest answer is that someone else's is the better fit for what you are building.