27 Client Discovery Questions to Ask Before You Quote a Project

Most bad quotes do not come from bad math. They come from a discovery call that skipped a question nobody thought to ask. The client mentioned it in passing, in month four, when the change order was already too expensive to raise cleanly.

This is the list we use before we scope anything. Twenty-seven questions, grouped into eight categories a client brief actually needs to answer. This is one piece of how we approach scoping a project from a raw brief — the discovery stage, before the estimate gets built. Ask all of them and you will still hit surprises. Skip half of them and the surprises will cost you margin.

For a deeper look at how we structure the brief itself before the quote stage, see our guide on writing a two-line project brief.

Business context

1. Why is this project happening now? Why we ask: A project driven by a compliance deadline moves differently than one driven by a founder's new idea. The urgency tells you how much room you have to push back on scope.

2. What happens if you do not do this? Why we ask: If nothing happens, the client has room to delay or cut budget mid-project. If something breaks, you have leverage to hold the timeline and the price.

3. Who else did you talk to about this? Why we ask: You need to know if you are the first call or the fourth. A client who has already been quoted twice has a number in their head. Find out what it is before you build yours.

4. Who inside your company asked for this? Why we ask: The person on the call is not always the person who wanted the project. If the real sponsor is someone else, you are scoping against secondhand requirements.

Scope

5. What is explicitly in scope? Why we ask: Get this in writing, in the client's own words. Vague scope on your side becomes unpaid scope later.

6. What is explicitly out of scope? Why we ask: Clients rarely volunteer this. Ask directly, or the boundary gets drawn during the project instead of before it.

7. Which features are must-have versus nice-to-have? Why we ask: Without this split, every feature gets treated as equally urgent. That is how a four-week build turns into a ten-week build with no formal scope change.

8. What does done look like, in the client's words? Why we ask: Your definition of done and the client's are not always the same. Get theirs before you write yours into the proposal.

Users

9. Who will actually use this? Why we ask: "Our team" is not an answer. Internal staff, external customers, and admin users need different things, and the difference changes the build.

10. How many people, roughly? Why we ask: Ten users and ten thousand users are different projects wearing the same feature list. Load, permissions, and support all scale off this number.

11. What roles or permission levels exist? Why we ask: Role-based access is easy to underestimate at the quoting stage and expensive to retrofit later.

Integrations

12. What existing systems does this need to connect to? Why we ask: Every integration is a dependency you do not control. List them now, not after the build starts.

13. Do you have API access to those systems, or do we need to build it? Why we ask: "We use Salesforce" and "we have an API key with write access to Salesforce" are two different quotes.

14. Who owns those other systems, and can they support this project's timeline? Why we ask: Your delivery date depends on a vendor or internal team you have never spoken to. Find out now if they can move as fast as you can.

Non-functionals

15. What traffic or usage volume do you expect? Why we ask: A tool for 50 internal employees and a public-facing product need different architecture. Ask before you scope the build, not after it falls over.

16. What uptime do you need? Why we ask: "It needs to just work" usually means something specific. Get the client to name a number, even a rough one.

17. Are there security or compliance requirements — HIPAA, SOC 2, GDPR, anything industry-specific? Why we ask: Compliance work is not a feature you add later. It shapes the architecture from day one, and it changes the price.

Constraints

18. What is the budget range? Why we ask: If they will not give you a number, ask what they spent on something comparable. A client with no anchor either has no budget yet or does not want to tell you.

19. What is the hard deadline, and why is it that date? Why we ask: "ASAP" is not a deadline. A trade show, a board meeting, or a contract renewal is. The real reason tells you if the date can move.

20. Who on your side is available, and how much time can they give this? Why we ask: A project stalls as often on the client's side as on yours. If their point person has 30 minutes a week, plan the timeline around that.

21. Are there any constraints we have not asked about? A tech stack you are locked into, a vendor you cannot use, a past project that failed? Why we ask: This is the catch-all question. Ask it last, after trust is built, because this is where clients admit the thing they did not think was relevant.

Decision process

22. Who signs off on this proposal? Why we ask: The person on the call is not always the person with a signature. Find the actual decision-maker before you write a 12-page proposal for the wrong reader.

23. What is the approval process on your side? One signature, or a committee? Why we ask: A one-signature client moves in days. A committee client moves in weeks. Your follow-up cadence should match.

24. What will this get compared against? Why we ask: You are rarely the only proposal on the table. Knowing what you are being measured against tells you what to emphasize.

Risk

25. Has anything like this been tried before, internally or with another vendor? Why we ask: A failed prior attempt is the single best predictor of what will go wrong this time. Ask directly what happened.

26. What has changed in scope on similar projects you have run? Why we ask: Past scope creep predicts future scope creep. If every project this client has run grew by 40%, budget for that pattern now.

27. What would kill this project internally? Why we ask: Budget cuts, a reorg, a champion leaving the company — most projects that die were killable from day one. Knowing the risk does not remove it, but it tells you where to build in contract protection.

Twenty-seven is a lot to hold in your head on a live call, especially the fourth one this week.

Or skip the manual version. Prophic AI reads the client's brief, asks the follow-up questions itself where the brief has gaps, and hands you back a scoped estimate against your own rate card and templates.

Turn a brief into a scoped proposal. Book a demo.