Skip to main content
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.
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.
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.
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.
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.

​
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.
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.
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.
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.
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.

​
Users

User type, count, and permission model have an outsized effect on scope. “Our team” is not an answer.
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.
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.
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.

​
Integrations

Every integration is a dependency you don’t control. The earlier you list them, the more accurately you can price them.
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.
“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.
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.

​
Non-Functionals

Performance, uptime, and compliance are often implied but never stated. Left unasked, they surface mid-build as scope changes.
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.
“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.
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.

​
Constraints

Budget, timeline, and availability on the client’s side all constrain delivery. Surface them before the proposal, not during it.
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.
“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.
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.
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.

​
Decision Process

Knowing who approves the proposal and what it gets compared against shapes how you write it.
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.
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.
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.

​
Risk

Past behaviour is the best predictor of what will go wrong. Ask directly.
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.
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.
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.
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.

Pre-Sales Best Practices

How to write better briefs, prevent scope creep, and respond to proposals faster.

Pre-Sales Workflow

How Prophic moves a brief through all five stages to produce a scoped, priced proposal.