How long should a discovery call be?

Sixty minutes is the right length for a first call, and forty-five is workable. Anything shorter forces you to skip the current process and jump to requirements, which is where the mistakes are made. If the operation is large or spans several departments, book a second call rather than extending the first one — in our experience attention drops after about an hour, and the answers get less precise.

Should you give a price on the discovery call?

Give a range, not a price. A range tells the client whether to continue and costs you nothing, while a specific figure given before you understand the data model and the integrations will be treated as a commitment. Send the written restatement of the problem within a day, and put the actual number at the end of a paid scoping phase where it can be defended with assumptions.

What if the client refuses to share a budget?

Offer a range first and ask which side of it they sit on. Most clients who will not name a figure will still confirm whether a project of that shape is plausible for them, which is all you need to decide whether to continue. If they will not engage with a range at all, and the person who signs is also absent, treat that as a qualification signal rather than a negotiation tactic.

The discovery call, done properly

A message arrives by email or WhatsApp: We need a system for inventory and invoices. Can you send a quotation? The temptation is to answer the question that was asked. A number goes out within two days and meets one of two fates — high enough that nobody replies, or low enough to win work that turns out to be three times the size estimated. The inquiry carried a solution and a deadline, and no description of the business that produced them.

The discovery call is the hour that turns an inquiry into something that can be scoped, priced and built, or that ends the conversation early enough that nobody loses money. Most of what determines which one happens is decided before anyone speaks, and by the order of the questions rather than their number.

Preparation is short and specific

Twenty to forty minutes before the call is enough, and more than that is usually wasted. Read the company's public surface: the website, the price list, the catalogue, the app if there is one, the last two months of comments on their social accounts. Complaints from customers are the most useful page on the internet for this purpose, because they describe the failure from outside the company, in plain language, and they are rarely the failure the client will describe to you first.

Then find the structural facts. How many branches, how many people, which sector and what that sector is regulated by. In Egypt this often means the Egyptian Tax Authority e-invoicing obligations, and whether the company is already compliant or is about to be forced into it. Check who you are actually meeting: the founder, the operations manager, an IT lead, or a consultant hired to run the selection.

Arrive with two things written down: three specifics you noticed, and two facts you could not determine from outside. The specifics show you spent the time. The gaps are your first questions.

The current process comes before the desired system

Open by asking how the work is done today, step by step, before asking anything about what should be built. This is the single most useful habit in the whole conversation, and it is the one most often skipped because the client opened with a request and it feels rude not to answer it.

There are four reasons for the order. The stated request is a solution the client has already designed, usually from a competitor's product or a demo they were shown, and designing is your work rather than theirs. The current process is the only reliable source of volume, roles and exceptions — how many orders a day, who approves a discount, what happens when a delivery is refused. People describe what they do far more accurately than what they want. And the system you build will be judged against the process it replaces, not against a specification.

The request also shrinks under this question, frequently in a useful direction. An "inventory system" turns out to be one Excel file edited by four people and a WhatsApp group between three branches, and the actual failure is that head office sees yesterday's stock, not today's. That is a smaller and much more definite problem than the one in the inquiry, and it can be solved first.

A client can be wrong about the system they need. They are almost never wrong about how they work today.

The questions, in order

The list below is the working order. It moves from process, to failure, to people and money, to time. Nothing about budget or dates comes before the client has described their own operation, because the answers are more honest once they have.

Walk me through how an order goes from the customer to delivery today. Who touches it at each step?
Who does that work — how many people, in which roles, in which branches or locations?
What is the volume: orders a day, SKUs, invoices a month, users who would need an account?
Which tools are in use now, and which of them are you paying for?
Where does it break? Describe the last time it went wrong.
What did that failure cost — in hours, in lost or returned goods, in penalties, in customers?
What have you already tried, and what happened to it?
Who else must be able to use this, and what must certain roles never be able to see?
What must it connect to: e-invoicing, the accounting file, the payment gateway, the shipping companies?
Who decides that this project goes ahead, and who signs the contract?
What range have you set aside for it?
When does it need to be running, and what happens on that date?
If we built one part first, which part would be worth having on its own?

Two of these need care. On budget, ask for a range and offer one first, so the question is answered rather than deflected: systems of this shape usually land between one figure and another, and you are asking whether that is the range they had in mind. The client is not obliged to reveal a number, but they will almost always tell you which side of it they are on, and that is enough. What a custom system costs, and why estimates differ covers how to frame those bands honestly.

On dates, the second half of question twelve does the work. A date with a reason behind it — an audit, a lease ending, a tax deadline, Ramadan, the start of the school season — is a constraint you can plan against and design around. A date with no reason is a wish, and it will move, usually after you have staffed for it.

The stated request is rarely the constraint

Most calls contain one sentence that matters more than the rest, and it is usually said in passing. A request for a mobile application turns out to be about sales representatives who cannot record a visit where there is no coverage, which is a question about offline capability, not about an app store. A request for dashboards is often a founder who does not trust the numbers they already have, which is a data integrity problem that no chart will fix. A request to integrate with the accounting system is usually a request to stop entering the same invoice twice.

Two questions surface this reliably. What would you do differently if you had that? and what happens if we build nothing at all? The first turns a feature into a decision someone wants to make. The second tells you whether the project has real pressure behind it or is a preference that will lose to the next urgent thing.

Repeat back what you heard in your own words before you move on. If the client corrects you, you have learned something. If they agree too quickly, ask for an example from last month.

Qualification is a decision made on the call

By the end of the hour you should know whether this project can work, and it is cheaper for both sides to say so then. A few signals are reliable enough to act on.

Signal on the call	What it usually means	Response
The person who signs is not in the conversation	You are being used to produce a document for an internal argument you cannot hear	Ask for a second call with that person before any pricing
The date came from someone outside the room	The deadline is not owned and will not be defended	Ask what was promised, to whom, and on what basis
"Build the same as X, but cheaper"	The buyer is comparing on price alone and has no model of what the work is	Offer a smaller first phase or decline
Reluctance to describe the current process	Either there is no process, or the internal politics of describing it are the real project	Decline, in most cases
No one internally will own answering questions weekly	The build will stall on decisions, not on code	Make a named owner a condition of the engagement
Payment tied to results, or offered as equity for a first project	The client is transferring their risk to you before either side knows the work	Decline

One of those is worth stating plainly. Unwillingness to describe how the work is done today is the strongest disqualifying signal there is, stronger than a small budget. Small budgets can be met with a smaller first phase. A client who will not open their operation to you will not open it during the build either, and that project shows the early signs of going wrong before it has started.

Say no in the call itself where you can, and within a day where you cannot. One paragraph: what you understood, why it is not a fit, and what would change that. Do not invent a scheduling excuse. Then give them something usable — an off-the-shelf product that fits, a smaller sequence they could do themselves, or the name of someone who takes work of that size. This costs one conversation and returns referrals for years, because a clear no is rare enough to be remembered and repeated.

What goes out within twenty-four hours

Send a written restatement of the problem, not a price. One page, in their vocabulary: the current process as you understood it, the failure points quoted close to their own words, the outcome they described wanting, the constraints and integrations, what you consider out of scope for now, the questions still open, and the proposed next step.

The restatement does three things a quotation cannot. It tests whether your account of the business is correct while a correction is still free. It gives the person who was in the room something to circulate to the person who signs, written in language that person recognises. And it moves the conversation off price comparison, because you are now discussing whether the description is right rather than whether the number is low.

The next step is a paid scoping phase with a fixed fee, a fixed duration and dated deliverables — the process map, the data model, the integration list, the phased plan and a price with its assumptions stated. That is where the estimate is earned rather than guessed, and Pricing, estimates, and the proposal that gets signed sets out what it should produce and how it is charged.

From a call to a scoped project

The discovery call is not a performance, and it is not the place to demonstrate what you can build. It is the place to find out what is true, in an order that makes the truth easy to tell.

To scope a project this way, write to Softwiro at softwiro.com with a description of how the work is done today. That paragraph is worth more than a specification.

The discovery call: from inquiry to a scoped project