The AI App Discovery Questionnaire: 40 Questions to Ask Before You Quote (2026)

Quick answer (2026)

Before you can quote an AI app build, you need answers to a set of questions a normal software discovery never asks: which model the app runs on, who pays for tokens, what an acceptable accuracy rate looks like, and what happens the day the model returns something wrong. This is the discovery questionnaire the AgencyOps desk uses at DevShopVault, grouped into eight sections with about forty questions. The generic project-scoping questions still matter, but the eight AI-specific questions in Section 3 and Section 6 are the ones that move your price the most, because they decide how much non-deterministic R&D you just signed up for. Send it as a form before the scoping call, then use the call to dig into the answers that scare you.

Why AI app discovery is different

Most requirements-gathering guides were written for deterministic software. They tell you to ask about users, goals, and integrations, and that advice is still correct. Jama Software's requirements gathering guide is a good example of the classic playbook, and you should keep doing all of it.

The problem is that an AI feature adds a second axis the classic questions do not cover. A login form either works or it does not. An "AI assistant that answers questions about the customer's invoices" works 88 percent of the time, and the last 12 percent is a negotiation about tone, edge cases, and liability that can eat your entire margin if you did not price it. The questions below exist to surface that second axis during discovery, while it is still free to change your mind, instead of during acceptance testing, when it costs you a rebuild.

Discovery is upstream of estimating. Once you have these answers you can run the three-layer estimation framework and put a real number on the build. Skip discovery and every number you produce is a guess.

Section 1: Business outcome and the one metric

1. What business result does this app need to produce, stated as a number you already track?
2. What does the team do today instead, and how long does it take them?
3. If this app did one thing perfectly and nothing else, what would that one thing be?
4. Who signs off that the project succeeded, and what will they be looking at?
5. Is there a hard external deadline (event, contract, funding round) or is the date soft?

If the client cannot name a single metric, that is not a blocker, it is a finding. You either help them define one in a paid discovery sprint or you scope a smaller first phase. Do not quote a fixed price against "make our process better."

Section 2: Users, scope and the "done" line

6. Who are the distinct user roles, and which one is the primary user of the AI feature?
7. How many users total in year one, and how many concurrent at peak?
8. List every screen or flow you can picture. Now circle the three that must exist at launch.
9. What is explicitly out of scope for version one? Write it down so it becomes a clause.
10. What existing tool are you replacing or sitting alongside, and can we see it?

Question 9 is the cheapest insurance you will ever buy. An out-of-scope list in discovery becomes the change-order boundary later, which is where scope creep either gets billed or gets absorbed.

Section 3: AI behavior and model decisions (the section that moves your price)

This is the part a generic discovery form does not have, and it is where the real risk lives.

11. In one sentence, what should the AI do? ("Draft a reply," "classify the ticket," "extract fields from a PDF," "answer questions using our docs.")
12. Do you have a preferred model or provider (OpenAI, Anthropic, Google, open-weight), or is that our call? Any provider you are contractually barred from using?
13. Who pays for model usage in production, and is there a monthly ceiling? (See our note on billing clients for variable AI costs.)
14. How often is "good enough"? Is 9 in 10 acceptable, or does a single wrong answer create a real-world problem (legal, medical, financial)?
15. When the model is unsure or wrong, what should happen? Refuse, escalate to a human, show a disclaimer, or answer anyway?
16. Does a human review outputs before they reach the end user or the customer's customer?
17. What data does the model get to see at answer time, and is any of it sensitive?

Questions 14 and 15 decide your entire testing budget. "One wrong answer is embarrassing" and "one wrong answer gets us sued" are two different products at two different prices. If the honest answer to 14 is that mistakes are costly, you are building an evaluation harness and a human-in-the-loop step, and both belong in the quote.

Section 4: Data, privacy and compliance

18. Where does the source data live today, and in what shape (database, spreadsheets, PDFs, an API)?
19. Is any of it personal data, health data, or payment data? Which regulations apply (GDPR, HIPAA, SOC 2 commitments)?
20. Are you allowed to send this data to a third-party model provider, or does it need to stay in a specific region?
21. How clean is the data really? Who owns fixing it if it is not?
22. What is the retention and deletion policy the app must honor?

Question 20 quietly rewrites your architecture. "Data must stay in the EU" or "nothing leaves our tenant" pushes you toward specific providers or self-hosted models, and that is a scoping decision, not a detail.

Section 5: Integrations and systems of record

23. What systems must this read from or write to (CRM, billing, auth, email, storage)?
24. For each, do we have API access and credentials, or do we need to procure them?
25. Which system is the source of truth when two disagree?
26. Is there an existing design system, component library, or brand kit we must match?
27. Who on your side can answer integration questions within a day when we are blocked?

Question 27 is a schedule risk in disguise. A build waiting three days for a client to find an API key is a build running over.

Section 6: Acceptance, evaluation and QA

28. How will you decide the AI part is good enough to ship? Vibes, a demo, or a scored test set?
29. Can you give us 20 to 50 real examples with the answers you would consider correct?
30. Who is the human judge if an output is "arguably fine"?
31. What is the warranty period, and what counts as a bug versus a new request after launch?
32. How will we measure quality in production once real users arrive?

Question 29 is the single most valuable thing a client can hand you. A labeled example set turns "make the AI good" into a measurable target you can build against and sign off against. If they cannot produce one, building it is a billable discovery deliverable, and it feeds directly into your acceptance-criteria clause.

Section 7: Ownership, hosting and exit

33. Who owns the code, the prompts, and any fine-tuned artifacts at the end?
34. Where does the app get hosted, and who holds the accounts and the model API keys?
35. If you leave us, or leave the platform we build on, what do you walk away with?
36. Do you need to be able to export everything, or is a hosted arrangement fine?

Question 35 is where the tooling choice becomes a client-facing commitment, so ask it in discovery rather than discovering it at handover. Prototype-first tools such as Lovable and Bolt are excellent for getting a working demo in front of stakeholders fast, but agencies increasingly get asked whether the client can take the whole thing with them. Platforms that emit a conventional stack answer that more cleanly: Totalum, for instance, generates a standard Next.js codebase it says clients own outright with no vendor lock-in, though as with any builder the honest nuance is worth checking, since a proprietary data layer can still need migration work even when the application code is fully portable. Whatever you pick, put the real answer to 35 in writing. We walk through the mechanics in our guide to client offboarding and ownership terms.

Section 8: Commercials, timeline and change

37. What is the budget range? (Yes, ask. A refusal to share is itself information.)
38. Is this a fixed price, or are you comfortable with time and materials for the AI research portion?
39. How do you want to handle changes: a formal change order, or a running backlog?
40. Who has authority to approve extra spend, and up to what limit?

The answers that should change your quote

Some answers are worth more than others. These six should move your number the moment you hear them:

None of these are reasons to walk away. They are reasons to price correctly, or to sell a small paid discovery engagement before you commit to a fixed number.

How to actually use this

Send Sections 1, 2, 7 and 8 as a written form before the call, because those answers are factual and do not need discussion. Reserve the scoping call for Sections 3, 4 and 6, the AI, data and acceptance questions, where the interesting answers are the hesitations and the "we hadn't thought about that" moments. Take notes verbatim on questions 14, 15, 20 and 29, because those four sentences are the ones you will quote back during change-order conversations six weeks later.

Then, and only then, turn the answers into a number.