I've sat on both sides of this table, as the vendor pitching the work and as the person evaluating who to bring in. The questions to ask a tech partner before signing anything are not complicated, but almost nobody asks them in the first meeting, and by the time the answers matter, the contract is already signed.

Most vendor selection focuses on price, portfolio, and timeline. Those matter, but they're the easy things to fake in a pitch. The questions below are harder to fake, because a vendor who's actually good at this work has clean answers, and a vendor who isn't will dodge, deflect, or give you an answer that sounds right but doesn't actually commit to anything.

Ask these before you sign, not after the first milestone slips.

1. Who actually writes the code, and where are they based?

Get specific. Is it the person in this meeting, a named team, or "our engineering pool" that changes project to project? Vague answers here predict inconsistent quality later. A good partner can tell you exactly who's on the team and what they've shipped before.

2. Who owns the code and the IP when the engagement ends?

This is the single most consequential question and the one owners skip most often. If the contract is silent or vague on IP ownership, assume the vendor's default position favors them, not you. You want explicit language: you own the code, the documentation, and the right to take it to any other developer without restriction. If a vendor hesitates here, that hesitation is the answer.

This connects directly to the build-versus-buy decision most owners face before they even choose a partner. If you haven't run that framework yet, it's worth doing first: Build vs Buy Software: A Decision Framework for Owners.

3. What happens when we disagree on scope?

Every project hits a moment where the client thought something was included and the vendor thought it was a change request. Ask them to describe, concretely, how that gets resolved. Good partners have a real process: a documented scope, a change request procedure, a named person who makes the call. Bad partners say "we'll work it out," which means whoever has more leverage wins, and early in the relationship that's usually them.

4. Tell me about a project that failed. What happened?

This is the single best predictor in the whole list, and it works because of how people answer it, not just what they say.

A vendor with real experience will tell you a specific story: what went wrong, what they missed, what they changed afterward. They'll own the parts that were their fault. A vendor who says "we don't really have failed projects" or gives you a story where the client was entirely to blame is telling you how they'll talk about your project when something goes wrong on it. Everything fails somewhere. The tell isn't the failure, it's the honesty about it.

5. How do you communicate bad news mid-project?

Ask this directly: if a deadline is going to slip, when do we hear about it, from whom, and how far in advance? Vendors who are good at delivery bad news early, with a plan attached, not an apology attached. Vendors who aren't tend to go quiet as the deadline approaches and then surface the problem at the last possible moment, when your options are worst.

6. What does the first 30 days look like, concretely?

You want a specific answer: discovery sessions, a technical audit, a scoped document, a kickoff milestone. Vague answers ("we'll get to know your business") mean the first month is unstructured and you're paying for their onboarding curve.

7. Who is our actual point of contact, and what's their availability?

Get a name, not a team. Ask how fast that person responds to a message and what happens if they're unavailable for a week. This matters more than it sounds, because the difference between a smooth engagement and a frustrating one is usually how fast questions get answered, not how good the code is.

8. Can we talk to a past client, ideally one where things didn't go perfectly?

References who only had smooth experiences are useful but limited. A reference where something went sideways and got resolved tells you far more about how the vendor operates under pressure, which is the condition that actually matters.

9. What's your position on documentation and handover?

Ask what documentation you'll receive: architecture decisions, setup instructions, environment access, admin credentials. A partner planning for a healthy long-term relationship documents as they go. A partner planning to make themselves indispensable keeps the knowledge in their heads, which is a trap whether or not they intend it that way.

10. How do you price change requests, and can we see an example?

Every project changes scope. Ask to see an actual example of how a past change request was estimated and priced, not just the policy. This shows you both their pricing logic and how much friction to expect when scope inevitably shifts.

The meta-signal across all ten

None of these questions are about technical skill, and that's deliberate. Most vendors at the table you're evaluating can write competent code. The differentiator is how they handle ownership, disagreement, and bad news, because those are the moments that determine whether the relationship survives past the first milestone. If you want a structured way to weigh vendor answers against building in-house first, our related piece on that decision is here: Build vs Buy Software: A Decision Framework for Owners.

The takeaway

Price and portfolio get you a shortlist. These ten questions decide who's actually trustworthy with your codebase and your budget once things get hard, which they will. Ask question 4 first if you only have time for one. How someone talks about their own failure tells you almost everything you need to know before you sign. If you're evaluating a tech partner right now and want a second, technical opinion on the answers you're getting, that's a conversation worth having at /partner.