You are about to spend somewhere between fifty thousand and a million dollars with people you have known for three weeks. The usual process — a shortlist, a capability deck each, a proposal, a reference call — is remarkably bad at predicting how the next year will go.
It is bad because every firm on the shortlist will show you a polished deck, name plausible technologies, and provide references who liked them. None of that discriminates. What discriminates is how a partner behaves when the answer is inconvenient.
Here is what to ask instead.
Ask them to disagree with you
Describe your intended solution and ask directly: what is wrong with this?
A partner who has done this work before will have an objection. Your scope is too large for one release. Your timeline assumes decisions you have not made. The integration you described as trivial is the actual project. You may not like the objection, and it may be wrong — but its presence tells you they were thinking rather than selling.
What should worry you: enthusiastic agreement. “Yes, we can absolutely do that, that’s very straightforward” is what someone says when they are optimising for winning the work rather than delivering it. The disagreement was going to happen regardless; you are choosing whether it happens now or in month five.
Ask what they would not build
Every competent partner has turned work down. Ask for an example and listen to the reason.
Good answers are specific and often unflattering to the speaker: the client would not commit a decision-maker; the technology was outside our competence and we had no partner for it; they wanted a fixed price on something we could not scope honestly.
What should worry you: “We take on any project.” That is not confidence, it is an absence of judgement — and judgement is the thing you are actually buying. A firm with no filter has no opinion about where it is effective.
Ask how a fixed price is produced
This one question separates most of the field.
The honest answer involves paid discovery: we cannot price what nobody has scoped, so we do a short fixed-fee engagement first, and the estimate comes out of that with its assumptions written down.
What should worry you: a firm price for a project defined in a two-page brief. That number is a guess, and guesses get corrected — through change requests, usually in the vendor’s favour and against yours. The apparent certainty you bought at signature is the thing you will spend the year losing.
Be suspicious, too, of anyone who promises a fixed scope, a fixed date and a fixed cost simultaneously on work with genuine uncertainty. Two of the three is honest. All three means someone is managing you rather than the risk.
Ask who will actually do the work
Meet them. Not the principal who runs the sales process — the people who will be in your repository on a Tuesday.
What should worry you: the senior person you are impressed by cannot tell you how much of their time you get, or the team is “to be assigned on award”. Senior presence during selection followed by juniors during delivery is the oldest pattern in this industry and it is still working.
Ask what happens when it goes wrong
Not if. Something will go wrong on a year-long software project; the question is what happens next.
Listen for mechanism rather than sentiment. How soon would we hear about a slipping milestone, and from whom? What is the change-control process? What happens if we disagree about whether something is in scope? Who is accountable if a release introduces a production incident?
What should worry you: “We have never had that happen.” Either untrue, or they have not done enough work to have encountered it.
Ask what you would own
Get it explicit before contracting, not during.
You should own the client-specific deliverables and your data outright. A partner will usually have pre-existing components they reuse across clients, which is reasonable and keeps your cost down — but the contract must distinguish the two, and those components must be licensed to you perpetually.
What should worry you: vagueness here, or a framework you cannot maintain without them. Sometimes the lock-in is the business model.
Ask how you would leave
The exit conversation during selection is uncomfortable and enormously informative.
A partner who has thought about continuity will describe runbooks, architecture decision records, credential handover and a transition period — usually as contract terms rather than favours. They write documentation for whoever inherits the system, on the assumption it may not be them.
What should worry you: a partner who treats the question as a lack of commitment. You are not proposing a divorce; you are checking that the work has a life beyond the relationship.
The reference call question that works
Most reference calls are useless because you ask whether the client was happy, and the reference was chosen because they were.
Ask this instead: what was the worst moment of the project, and how did they handle it?
Every real engagement has one. A reference who cannot recall a bad moment either was not paying attention or is not a real reference. The valuable answer is a specific story about a partner who raised a problem early, took responsibility, and proposed options — because that is the behaviour you are actually buying.
What none of this measures
Notice what is absent: technology-stack quizzes, team size, years in business, certification badges, and the logo wall.
Those are not irrelevant, but they are table stakes and every shortlisted firm will clear them. They do not predict outcomes. The behaviours above do, because software projects rarely fail on technical capability. They fail on judgement, communication and the willingness to say something unwelcome while it is still cheap to hear.
A short checklist
- Do they disagree with me about anything?
- Can they name work they turned down, and why?
- Does a fixed price come after paid discovery, or before?
- Have I met the people who will do the work?
- Do I know the mechanism for bad news?
- Is IP ownership explicit in writing?
- Do I know how I would leave?
- Did the reference describe a real bad moment?
If a partner clears those, the technology conversation is comparatively easy. If they do not, no amount of technical excellence will save the engagement.
Written by WeInDev. If this is a decision you are facing now, it is also a conversation we are happy to have — thirty minutes, no pitch deck.