A portfolio shows you what a supplier can build. These questions show you what it will be like to work with them and what you will be left holding.
On ownership
Will the intellectual property be assigned to us, in the contract, effective at delivery? Assignment, not a licence. If the answer involves a perpetual licence, ask why.
What is excluded from the assignment, and under what terms do we hold it? Some reuse of generic internal tooling is reasonable. Reuse of the core of your system is not. Get the list.
Who will the domain, hosting, database and third party accounts be registered to? If any of them are in the supplier name, you cannot leave without a migration. This should be your organisation from the start.
Will we get the full repository with history? A single commit called initial delivery discards the record of why decisions were made.
On the work itself
What documentation is delivered, and will a person who was not on the project be able to deploy from it? Ask whether anyone has tested that. The answer is usually no, and asking makes it more likely someone does.
Will you perform a restore from backup and tell us how long it took? A backup nobody has restored is a hypothesis. The recovery time should be a measured number in a runbook.
What is your approach to testing, and what will be covered? A percentage is not an answer. What you want is a list of the behaviours that carry money, time and access, and confirmation that those are covered.
On the relationship
How is scope agreed, and what happens when it changes? You want a written specification before the build and a documented change process with cost and schedule impact stated. Agreeing this in advance is what keeps it from becoming a dispute.
Who will we actually work with, and who is accountable? A named project manager and a technical lead. If the answer is vague, the accountability will be too.
What is your process when you disagree with what we have asked for? A supplier who always agrees is not thinking. You want one that will tell you when an existing tool would solve the problem or when the answer is a process change rather than software.
The two that matter most
If we chose a different supplier in two years, what would they need from you, and would they get it?
This question does more work than any other. A supplier confident in their handover answers it directly and specifically. One who becomes vague is telling you that leaving is intended to be difficult.
What have you built that did not work, and what did you learn?
Everyone has one. A supplier who claims otherwise is either inexperienced or not being straight with you. The useful answer is specific about what went wrong and what changed as a result.
What to watch for in the answers
Confidence about things nobody can know. An exact delivery date for a system whose scope has not been written is a sales answer.
Certifications implied rather than held. Ask directly whether they hold a specific certification and expect a yes or a no.
Statistics without a source. A supplier quoting improvement percentages from previous work should be able to say how it was measured and whether the client agreed the figure.
Reluctance to talk about what happens at the end. The end of the engagement is the part that determines what the work was worth.
What good looks like
A supplier who asks more questions than you expected in the first conversation, tells you where they think the risk is, is willing to say that part of what you asked for is not worth building, and is completely relaxed about you owning everything afterwards.
Look for answers specific enough to become delivery obligations and acceptance checks, not only a comfortable first conversation.
Ask for evidence appropriate to the answer
If a supplier says deployment is repeatable, ask what command builds the product and what environment it was tested in. If they say a form sends email, distinguish a mocked test from a message accepted by the real provider. If they claim strong accessibility, ask which routes, interactions and assistive technologies were exercised.
The evidence need not expose another client's confidential work. A redacted test report, a technical walkthrough or a demonstration using nonproduction data can explain the method without revealing private records. Respect that boundary rather than treating access to client information as proof of competence.
Separate three categories in your notes: established facts, proposed delivery commitments and unresolved questions. A supplier may have a sound plan for an integration whose credentials are not yet available. That is different from claiming the integration was already tested. Keep the unresolved item visible until the required access or a suitable test environment exists.
Ask how decisions will reach the project manager, team lead, engineers and QA. A technically correct answer from one person does not help if the delivery team works from a different assumption. Agree where scope decisions and acceptance examples will be recorded, and how changes are approved.
Finally have the commercial and IP terms reviewed for your circumstances. Engineering questions can expose practical dependence on a supplier, but they do not replace legal review of the agreement. The useful outcome is a shared record of what will be delivered, how it will be verified and what remains the client's responsibility after handover.