Guide question list
Ten questions to ask any AI studio before you pay, including us
Buying AI work is hard to judge from the outside. These questions make a studio show how it works before you sign. Ask every team the same ones, write the answers down, and compare.
In short: before you pay an AI studio, ask what will exist at the end and how you will both know it is done, what it costs, who owns the code, who does the work, what you can check, what runs each week, how quality is measured, what could make it fail, when AI is the wrong tool, and how you leave.
How to use the list
Ask in writing, or take notes during the call. A good team answers most of these without hesitating, because the answers are part of how it already works. Vague answers are not proof of a bad team, but they tell you where to look harder. A copyable version is at the end.
For a wider view of buying AI, two public documents are worth reading: the UK government's Guidelines for AI procurement and the US AI Risk Management Framework from NIST. Both are listed under sources.
The ten questions
Q1 What exactly will exist at the end, and how will we both know it is done?
- Why ask
- Most disputes start with two different pictures of the deliverable.
- A useful answer
- One named deliverable, and checks that someone outside the team could run.
- A warning sign
- “We will explore the data and see what is possible.”
Q2 What will it cost, and what happens if the scope changes?
- Why ask
- Open-ended billing moves the risk of every surprise onto you.
- A useful answer
- A fixed price for a fixed scope, and changes agreed in writing before work on them starts.
- A warning sign
- A price that only appears after the work has begun.
Q3 Where does the code live, and who owns it?
- Why ask
- Code held by the studio is code you may have to buy back.
- A useful answer
- In your repository and your accounts from the first commit, owned by you.
- A warning sign
- A handover “at the end”, or a platform only the studio can run.
Q4 Who will do the work, and can I talk to them?
- Why ask
- The people in the sales call are not always the people who write the code.
- A useful answer
- You talk directly with the engineers doing the work, and you are told before anyone new joins.
- A warning sign
- Every question goes through an account manager.
Q5 What can you show me that I can check?
- Why ask
- Claims are cheap. Things you can read, run or verify are not.
- A useful answer
- Work you can inspect: code, a written method, a sample scope, or a small paid first step you judge yourself.
- A warning sign
- Logos and results you cannot check, with no way to ask the client.
Q6 What will I be able to run each week?
- Why ask
- Progress you cannot run is progress you have to take on trust.
- A useful answer
- A working version each week, in your accounts, that you can run yourself.
- A warning sign
- Weekly slides and nothing to run until the end.
Q7 How will you measure whether it is good, and against what?
- Why ask
- A score with nothing to compare it to cannot tell you whether the work helped.
- A useful answer
- Data the model never saw, a simple baseline to beat, and the weak cases shown next to the strong ones.
- A warning sign
- One impressive number, and no baseline.
Q8 What would make this project fail?
- Why ask
- A team that has thought about failure is more likely to avoid it.
- A useful answer
- Specific risks, such as missing data, unclear success or access delays, and what happens if one comes true.
- A warning sign
- “Nothing. We have done this many times.”
Q9 When would you tell me not to use AI for this?
- Why ask
- Some problems are better solved by a rule, a query or a spreadsheet.
- A useful answer
- Clear cases where they would say no, and a willingness to say it now, before you pay.
- A warning sign
- Every problem you describe needs AI, and more of it.
Q10 What happens after launch, and how do we part ways?
- Why ask
- Models need watching after launch, and you need a way out that does not break anything.
- A useful answer
- Monitoring, a runbook and retraining steps your team can follow, and the right to stop after the first piece of work.
- A warning sign
- A long contract before any work has been shown.
Our own answers, in short
The title says “including us”, so here are ours. They are the terms we start from, and you can hold us to them.
- Q1 and Q2. A fixed-price, fixed-scope pilot with one deliverable, agreed in writing before it starts. See the sample scope.
- Q3. Your repository and your accounts, from the first commit.
- Q4. You talk to the engineer doing the work.
- Q5. We are a new studio. What we can show you today is on the about page.
- Q6. Something you can run, every week.
- Q7. The written scope says what “done” means as checks anyone can run, and what they are measured against. See the sample scope.
- Q8. The written scope names what is out of scope and what happens if something proves impossible.
- Q9. If AI is the wrong tool, we say so when we scope the work.
- Q10. You can stop after the pilot and keep everything it produced.
Copy the question list
TEN QUESTIONS TO ASK ANY AI STUDIO BEFORE YOU PAY
Source: mattersettle.com/guides/questions-before-you-pay/
Studio: ____________________ Date: __________
Q1 What exactly will exist at the end, and how will we both know it is done?
Notes:
Q2 What will it cost, and what happens if the scope changes?
Notes:
Q3 Where does the code live, and who owns it?
Notes:
Q4 Who will do the work, and can I talk to them?
Notes:
Q5 What can you show me that I can check?
Notes:
Q6 What will I be able to run each week?
Notes:
Q7 How will you measure whether it is good, and against what?
Notes:
Q8 What would make this project fail?
Notes:
Q9 When would you tell me not to use AI for this?
Notes:
Q10 What happens after launch, and how do we part ways?
Notes:
Sources
- Guidelines for AI procurement. UK Office for Artificial Intelligence, GOV.UK, June 2020. Read 2026-10-16.
- AI Risk Management Framework (AI RMF 1.0). US National Institute of Standards and Technology, January 2023. Read 2026-10-16.
Both are cited as further reading on buying and managing AI. The questions above are original and are not taken from either document.
How this guide was written
Matter Settle publishes this guide without a byline. Its steps come from common engineering practice, not from any client project, and every example in it is invented. Outside work is cited above as background only, with the date it was read. The guide was last reviewed on . If you find a mistake, tell us: the guide will be corrected and its review date changed.