> ## Documentation Index
> Fetch the complete documentation index at: https://docs.prophic.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 27 Client Discovery Questions Before You Quote a Project

> A categorised reference of every question to ask before scoping — covering business context, users, integrations, constraints, risk, and more.

Most bad quotes don't come from bad math. They come from a discovery call that skipped a question nobody thought to ask — one the client mentioned in passing, in month four, when raising a change order was already too expensive to do cleanly. The 27 questions below are grouped into eight categories that a client brief actually needs to answer. Ask all of them and you'll still hit surprises. Skip half and the surprises will cost you margin.

## Business Context

Understanding why a project is happening — and what happens if it doesn't — tells you more about risk, urgency, and budget than any feature list.

<Accordion title="1. Why is this project happening now?">
  A project driven by a compliance deadline moves differently than one driven by a founder's idea. The urgency tells you how much room you have to push back on scope, and whether a phased delivery is realistic.
</Accordion>

<Accordion title="2. What happens if you don't do this?">
  If the answer is "nothing much," the client has room to delay or cut budget mid-project. If something breaks without this, you have the leverage to hold the timeline and the price — and you'll want to reflect that risk in the proposal.
</Accordion>

<Accordion title="3. Who else did you talk to about this?">
  You need to know whether you're the first call or the fourth. A client who has already received two quotes has a number in their head. Find out what that number is before you build yours.
</Accordion>

<Accordion title="4. Who inside your company asked for this?">
  The person on the call isn't always the person who wanted the project. If the real sponsor is someone else, you're scoping against secondhand requirements — and the real decision-maker may push back on the scope you agreed with their delegate.
</Accordion>

***

## Scope

Getting scope boundaries in writing — in the client's own words — is the single most effective way to prevent a "of course that was included" conversation later.

<Accordion title="5. What is explicitly in scope?">
  Ask for this in writing, in the client's own words. Vague scope on your side becomes unpaid work later. "A booking system" and "a booking system with waitlists, cancellation windows, and timezone-aware scheduling" are not the same quote.
</Accordion>

<Accordion title="6. What is explicitly out of scope?">
  Clients rarely volunteer this. Ask directly. If you don't define the boundary before the proposal, the client will define it during delivery — and their definition will be broader than yours.
</Accordion>

<Accordion title="7. Which features are must-have vs nice-to-have?">
  Without this split, every feature gets treated as equally urgent. That's how a four-week build turns into a ten-week build with no formal scope change. Prioritisation also helps if budget is constrained.
</Accordion>

<Accordion title="8. What does done look like, in the client's words?">
  Your definition of done and the client's are not always the same. Get theirs before you write yours into the proposal. "Working" means different things to different stakeholders.
</Accordion>

***

## Users

User type, count, and permission model have an outsized effect on scope. "Our team" is not an answer.

<Accordion title="9. Who will actually use this?">
  Internal staff, external customers, and admin users need different things, and the difference changes the build. A job board with candidates, employers, and admins is a different scope than an internal tool with one user type.
</Accordion>

<Accordion title="10. How many people, roughly?">
  Ten users and ten thousand users are different projects wearing the same feature list. Load, permissions, and infrastructure requirements all scale off this number. Even a rough order of magnitude shapes the estimate.
</Accordion>

<Accordion title="11. What roles or permission levels exist?">
  Role-based access is easy to underestimate at the quoting stage and expensive to retrofit after the build starts. Name every role now, including any admin or internal-only permissions.
</Accordion>

***

## Integrations

Every integration is a dependency you don't control. The earlier you list them, the more accurately you can price them.

<Accordion title="12. What existing systems does this need to connect to?">
  List every integration now, not after the build starts. "We use Salesforce" sounds simple; the actual integration scope depends entirely on what data flows where and at what frequency.
</Accordion>

<Accordion title="13. Do you have API access to those systems, or do we need to build it?">
  "We use Salesforce" and "we have an API key with write access to Salesforce" are two different quotes. The difference can be weeks of work.
</Accordion>

<Accordion title="14. Who owns those other systems, and can they support this timeline?">
  Your delivery date depends on a vendor or internal team you've never spoken to. Find out now whether they can move as fast as you can — before you commit to a date in the proposal.
</Accordion>

***

## Non-Functionals

Performance, uptime, and compliance are often implied but never stated. Left unasked, they surface mid-build as scope changes.

<Accordion title="15. What traffic or usage volume do you expect?">
  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 under load.
</Accordion>

<Accordion title="16. What uptime do you need?">
  "It needs to just work" usually means something specific. Get the client to name a number or a tier, even roughly. Five nines is a different cost to three nines.
</Accordion>

<Accordion title="17. Are there security or compliance requirements (HIPAA, SOC 2, GDPR)?">
  Compliance work is not a feature you layer on after the build. It shapes architecture from day one and materially changes the price. Ask for the full list of requirements — including anything industry-specific — before you write a single line of the WBS.
</Accordion>

***

## Constraints

Budget, timeline, and availability on the client's side all constrain delivery. Surface them before the proposal, not during it.

<Accordion title="18. What is the budget range?">
  If they won't give you a number, ask what they spent on something comparable. A client with no anchor either has no budget yet or doesn't want to tell you — and both of those are useful things to know.
</Accordion>

<Accordion title="19. What is the hard deadline, and why is that date?">
  "ASAP" is not a deadline. A trade show, a board meeting, or a contract renewal is. The real reason tells you whether the date can move — and whether rush pricing applies.
</Accordion>

<Accordion title="20. Who on your side is available, and how much time can they give this?">
  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 — or price in the cost of delays it will cause.
</Accordion>

<Accordion title="21. Are there any constraints we haven't asked about?">
  Ask this last, after trust is built. This is where clients admit the thing they didn't think was relevant — a tech stack they're locked into, a vendor they can't use, a past project that failed.
</Accordion>

***

## Decision Process

Knowing who approves the proposal and what it gets compared against shapes how you write it.

<Accordion title="22. Who signs off on this proposal?">
  The person on the call isn't always the person with a signature. Find the actual decision-maker before you write a 12-page proposal for the wrong reader.
</Accordion>

<Accordion title="23. What is the approval process — one signature or a committee?">
  A one-signature client moves in days. A committee client moves in weeks. Your follow-up cadence — and your proposal length — should match the approval process, not your preference.
</Accordion>

<Accordion title="24. What will this get compared against?">
  You're rarely the only proposal on the table. Knowing what you're being measured against tells you what to emphasise — and tells you if you're in a price race or a quality race.
</Accordion>

***

## Risk

Past behaviour is the best predictor of what will go wrong. Ask directly.

<Accordion title="25. Has anything like this been tried before?">
  A failed prior attempt is the single best predictor of what will go wrong this time. Ask directly what happened — and design the proposal to address that specific failure mode.
</Accordion>

<Accordion title="26. What has changed in scope on similar projects you've run?">
  Past scope creep predicts future scope creep. If every project this client has run grew by 40%, budget for that pattern. It also tells you which exclusions to write with more specificity.
</Accordion>

<Accordion title="27. What would kill this project internally?">
  Budget cuts, a reorg, a champion leaving the company — most projects that die were killable from day one. Knowing the risk doesn't remove it, but it tells you where to build in contract protection.
</Accordion>

***

<Note>
  Twenty-seven questions is a lot to hold in your head on a live discovery call. Prophic's Requirement Analysis stage reads the client's brief and automatically surfaces gaps — acting as a built-in discovery layer even when you can't run a full discovery call first. If the brief doesn't answer a question that matters, Requirement Analysis will flag it as an assumption for you to confirm before the estimate is built.
</Note>

<CardGroup cols={2}>
  <Card title="Pre-Sales Best Practices" icon="shield-check" href="/resources/scoping-best-practices">
    How to write better briefs, prevent scope creep, and respond to proposals faster.
  </Card>

  <Card title="Pre-Sales Workflow" icon="arrow-right-arrow-left" href="/concepts/pre-sales-workflow">
    How Prophic moves a brief through all five stages to produce a scoped, priced proposal.
  </Card>
</CardGroup>


## Related topics

- [Create a Project and Run the Scope Pipeline](/guides/creating-a-project.md)
- [Projects vs Quick Quotes: Choose the Right Workflow](/concepts/projects-vs-quick-quotes.md)
- [How Prophic's 5-Stage Pre-Sales Pipeline Works](/concepts/pre-sales-workflow.md)
- [Quickstart: From Client Brief to Proposal in Minutes](/quickstart.md)