What Happens in a Discovery Call at SmartEdge IT Solutions

A discovery call is the only point in a project where a mistake is cheap. Everything afterwards — the estimate, the contract, the first sprint, the second one — inherits whatever was left unclear on the call. It is also the point where the most comfortable thing to do is quote a price, and that is precisely what makes it worth writing down properly.

Most of what gets published about discovery calls is sales technique rather than engineering. This is what actually happens on ours at SmartEdge IT Solutions, including the parts that do not flatter us. If you are preparing for one of these calls, the useful part starts in the next section.

Before the call, there is an email exchange

The call is not the first contact. Somebody sends a form, a message arrives, and we reply with a handful of questions before proposing a time. They are deliberately few, because the goal is to find out whether a conversation is worth having rather than to extract requirements over email.

What we usually ask at that stage: what the business does and who uses the thing being discussed, what exists today, what prompted the enquiry now, and whether there is a fixed date. That last one matters more than it looks. A deadline driven by an external event behaves completely differently from one driven by internal frustration, and the second kind usually moves.

We also do our own reading. If there is an existing site, we look at it. If there is a product, we look at whatever is public about it. If somebody has sent a requirements document, somebody on our side reads it before the call rather than during it. Coming into a call having skimmed the brief at the last second produces exactly the conversation everybody dreads.

And if we do not think we are the right firm, we say so at this point and point somewhere else if we can. That happens reasonably often and it is not a negotiating position — a mismatch found in week one costs both sides a month.

Who is on the call, and why it varies

Usually two people from our side, occasionally one. A larger group sounds collaborative and is not: more voices means less candour, and the useful part of a discovery call is the parts where somebody says the thing they were not sure they should say. We also keep internal roles off the call where we can. A proposal arriving from an account contacter and an engineer can sometimes be read as pressure.

From your side, the combination that works is a decision-maker and somebody who knows how the work happens now. Sometimes that is two people, sometimes it is one person wearing both hats. What does not work is a marketing person alone, because they can describe the ambition but not the constraints, and we will spend the call guessing at the constraints.

If the call is set up with only a marketing contact, we will ask to include whoever will own the work internally. If that is genuinely impossible, we still take the call and simply flag at the end which questions remain open.

The first fifteen minutes are about the business

We resist questions about frameworks, hosting and timelines for as long as we can, because answering those first reliably produces a conversation about the wrong things. The opening questions are about the work:

• What happens today, and who does it? Usually by hand, in a spreadsheet, by one person who knows the process.
• What goes wrong most often? The answer is frequently a single point of failure rather than a software problem.
• What did you try already, and why did it stop? This is the most informative question on the list and the one most often skipped.
• What would make this obviously worth having? Answered in terms somebody in the business would recognise.
• Who is affected if it is not fixed this year? Sometimes the answer is “nobody”, and that is worth knowing early.

Alongside those, the existing estate. What is already running, who looks after it, whether it has to keep running while the new thing is built, and whether anybody has tried to maintain it. A surprising number of enquiries come from an internal tool that one person wrote years ago and nobody has the source for.

The things we ask you to show us

Asking to see things is the most reliable way to move from intentions to specifics. The usual list, roughly in order of how often it turns out to matter:

1. The current website or product, and whatever analytics exist for it.
2. The spreadsheet or document that the business currently runs on. It is nearly always the real specification.
3. Recent support tickets or emails about the problem. Real language beats any brief.
4. Screens of the internal tool that does the job today, however crude.
5. Whatever exists in version control, if it is an existing product rather than a new build.

Two things we do not do. We do not run a security review on a video call, and we do not ask for production access or customer data during discovery. If either becomes relevant it happens as a separate, scoped piece of work with an agreement behind it.

Questions that feel like an interrogation

These are the ones clients least expect, and they change the quality of everything that follows.

• Who can block this, and who has to agree to it? Often a different answer from who asked for it.
• What is the decision date? Not the delivery date — the date a decision gets made.
• Are you talking to other suppliers? Always fair, and the answer tells us how the proposal will be read.
• What budget band are we working with, even roughly? Because a responsible proposal cannot be produced without it, and pretending otherwise wastes everybody’s time.
• If we said no, what would you do instead? Sometimes the honest answer is a spreadsheet and one enthusiastic person.
• What is already broken that you have not mentioned? The problem that gets raised in month two rather than month one.
• Who maintains this after launch? A question with no answer at this stage tends to resurface later at cost.

The budget question deserves a note. We ask it on the call rather than after a proposal because we cannot write a responsible estimate without it, and a proposal that misses the band by a wide margin is worse than an honest conversation. Where somebody does not want to disclose a figure, we will usually suggest they tell us whether the work we would describe fits a small, medium or large budget, which is enough for us to react usefully.

What we will not do on the call

No price. Not even a range, and not even “it would typically be something like”. A number given in a thirty-minute call is a guess dressed as a commitment, and it anchors the conversation badly. If somebody presses for a figure on the call, the answer is a written proposal with the assumptions attached.

Dates, then. Delivery timelines depend on the size of the team available and on decisions we have not yet discussed. Promising a date before either is settled is how projects slip quietly.

Platform demonstrations are out too. Showing a product because it happens to be one we use is persuasion rather than engineering, and it skips the part that matters — whether it fits your situation. If a technical comparison is useful, it belongs in writing afterwards.

And there is no “we can definitely do that”. When we hear a requirement we are unsure about, we say we are unsure and describe what we would need to check. That answer costs less than the alternative, which is a commitment made in a meeting and revised during delivery.

Where these calls go wrong

We have sat on both sides of this, so the failure list is fair to mention. The most common pattern is that the call becomes a presentation in reverse: the client walks through a document and the conversation is reduced to nodding at features. Nothing wrong is heard, and the estimate later looks optimistic for reasons that were visible in the first ten minutes.

Second pattern: the technical questioner is not technical. Somebody in a different role answers how the existing system works, from a summary they were given. The summary is not wrong, it is just missing the parts that determine cost — an export that cannot be produced, a licence held by a different company, a database nobody has touched in years.

Third pattern: nobody mentions what has to keep running. There is an existing system with real users, and the assumption is that the new build will simply replace it. Somebody then has to explain to those users what happened to their login, and that conversation is much harder than raising it on the call.

Fourth: the deadline is a marketing date that was set before anybody asked what was involved. Our application consulting and strategy work usually starts precisely here, because the useful question is which part of the date is actually fixed — a launch, a campaign, a contract renewal, a board meeting.

What arrives in writing afterwards

Within a working day or two, you get a short written summary of what we understood. Not a proposal — a short document covering the problem as we heard it, the users, the constraints, the open questions, and anything we think is in scope but not mentioned.

This is the most useful artefact of the whole stage, and we would argue for it more than for anything else in the process. It is short enough to be read and corrected, and a correction at this point costs an email. The same correction at the point of a signed contract costs a change request. Several projects have been visibly reshaped by a client replying to one of these with “actually, that part is optional”.

After that we propose a next step rather than assuming one. Usually one of three things: a short written scoping and estimate for work that is already clear enough; a paid discovery or technical spike where it is not; or a straightforward conversation to point you somewhere else. Our how we work page describes the stages in more detail.

When we say no

There are projects we decline, and being direct about it early is more useful to both sides than a slow no.

• The work is smaller than a project. If it is a fix, a small site or a script, an honest answer with a referral is better than an agency-shaped invoice.
• We would be the wrong specialism. Our service list is broad and it is not a claim that we are competent at everything. Some briefs belong with a firm whose whole practice is that one thing.
• The date cannot be met responsibly. Saying yes to a deadline and staffing it thinly helps nobody, especially not the launch date.
• The budget does not cover a version we would be willing to hand over. We would rather decline than build something we would not use ourselves.
• Team availability. We only propose work we can staff with people who will actually be on it. Sometimes that means telling a prospective client we cannot start in the window they need.

If none of that applies, the next step is straightforward — you can send the details through the contact page, and if there is a role rather than a product in mind, hiring developers from SmartEdge IT Solutions covers how that route differs. We would rather have one honest conversation than four that end politely nowhere.