A supplier discovery meeting is the first proper working conversation between your business and a potential development partner. Its purpose is not to receive a sales presentation or a price. It is to find out how the supplier thinks about problems like yours, what they need to understand before they can plan work, and whether their approach fits the way your organisation makes decisions.
The distinction matters because many agencies treat an initial meeting as a qualification call for their own pipeline. You are there to qualify them. That means setting the agenda, controlling the time, and structuring the conversation so you can compare suppliers on the same basis.
A focused 60–90 minute agenda
| Part | Purpose |
|---|---|
| Business context | Explain the problem, affected users and desired outcome. |
| Process and exceptions | Walk through the normal flow and the cases that create most operational difficulty. |
| Data and integrations | Identify sources of record, migration needs and external dependencies. |
| Supplier approach | Ask how uncertainty would be investigated and how evidence would shape the plan. |
| Close | Record open questions, requested evidence, owners and the next decision point. |
Who should attend
Bring at least two people from your side: someone who owns the business outcome and someone who understands the current process, data or system in detail. If only a business stakeholder attends, the supplier cannot ask the questions that reveal technical depth. If only a technical lead attends, the supplier misses the commercial context that shapes real priorities. For legacy modernisation work, include whoever currently maintains or depends on the existing system.
What a discovery meeting is not
It is not a requirements-gathering session. That comes later, usually as a paid or scoped phase. It is not a pitch. You should not expect, or allow, a lengthy slide deck about the supplier's history. It is also not the point at which you hand over confidential data, customer lists or server credentials. The meeting should work with process descriptions, role names and structural examples rather than live data.
Setting expectations beforehand
Send a brief agenda in advance. State the business problem, the type of system you are considering, the rough scale (number of users, data volumes, integrations you already know about), and what you want from the meeting itself. A simple framing such as "we want to understand how you would approach scoping this work" shifts the dynamic from a sales call to a professional consultation.
Structuring the conversation
Open with a concise description of the business problem: what is happening now, where it breaks down, and what outcome you need. Keep this to a few minutes. Then give the supplier the floor to ask questions. The questions they choose to ask first tell you more than their answers later. A supplier who immediately asks about user roles, data sources and integration points is thinking about the right things. One who jumps to technology choices or visual design before understanding the process is not.
After their questions, move to a structured section on approach. Ask how they would move from this meeting to a scoped proposal. What would they need to see? How long would that take? Would they produce a specification, a wireframe, or something else? This reveals whether they have a repeatable process or whether every project starts from a blank sheet.
Different scenarios demand different focus
For a customer portal, the conversation should cover authentication methods, what external systems hold the data the portal needs to display, and how you will handle user support queries. For a CRM replacement, the focus should shift to data migration, integration with existing tools, and how the supplier would handle the gap between your current processes and the new system's capabilities. For legacy modernisation, the supplier needs to ask about existing documentation, database structure, and whether the current system can be kept running during a phased migration.
In each case, the right questions from the supplier will differ. If a supplier asks the same generic questions regardless of whether you are building a portal, replacing a CRM or modernising legacy code, that is a useful signal about their depth in your particular type of work.
What to share and what to hold back
Describe processes in terms of roles and steps rather than naming specific individuals. Use structural examples for data: "we hold around this many records with these types of fields" rather than sharing a database export. Mention integration targets by system type and protocol where you know them: "we need to push data to an accounting system via API" rather than naming the supplier and version at this stage.
The reason is not secrecy. It is that premature detail creates a false sense of precision. A supplier who gives you a confident estimate based on ten minutes of description is not being thorough. One who says "we would need to understand the data structure and the API documentation before estimating that part" is being honest.
What to listen for
- Do they ask about exceptions and edge cases, or only the happy path?
- Do they distinguish between what you need now and what might come later?
- Do they raise risks, or only talk about benefits?
- Do they ask who will own the specification, the source code and the hosting environment?
- Do they mention testing, acceptance criteria or how you will know the work is finished?
A supplier who touches on several of these without prompting is likely to produce a more robust proposal and a smoother project.
Treating the meeting as a free scoping session
Some buyers try to extract a full requirements document or a fixed-price estimate from a single discovery meeting. This rarely ends well. The supplier either undercuts the work to win the business, leading to scope disputes later, or refuses and you interpret that as unhelpful. A discovery meeting should produce a shared understanding of the problem and a clear next step, not a deliverable.
Answering your own questions
If you talk for most of the meeting, you learn nothing about the supplier. State the problem concisely, then stop. Let them work with what you have given them. If their questions are shallow, that is information you need. If they are incisive, that is information too. Either way, you only find out by giving them space.
Not running the same meeting with more than one supplier
A single discovery meeting gives you an impression, not a comparison. Run the same basic agenda with at least two or three suppliers. You will quickly notice which ones ask similar questions and which ones miss things the others caught. That pattern is more reliable than any individual meeting.
Confusing confidence with competence
A supplier who promises a clear path and a simple answer may simply be ignoring complexity. One who says "there are three ways to approach this, each with different trade-offs around cost, risk and timeline" is doing more work in the room, even if it feels less reassuring. In business systems, the honest answer is usually qualified.
What to record before the meeting ends
Before you close, confirm three things. First, what will the supplier send you afterwards and when? A written summary of their understanding is a minimum; a structured proposal with options is better. Second, what do they need from you to produce that output, and by when? Third, who will be your point of contact if you proceed, and will the people in the room be the people doing the work?
These checks sound procedural, but they matter. A supplier who cannot clearly describe their own next step is unlikely to manage a complex build reliably. One who promises senior involvement but cannot confirm it in writing is creating a risk you will discover later.
Recognising the limitations
A discovery meeting cannot replace a proper discovery phase. It will not give you a reliable estimate, a full risk register or a detailed specification. What it can give you is enough evidence to decide whether to invest in a more thorough scoping exercise with that supplier. Treat it as a filter, not a decision point, and you will get more value from the time spent.
What a good meeting should produce
- A clearer account of the problem, not merely a longer feature list.
- Visible assumptions and unknowns that affect feasibility, cost or timing.
- Evidence of how the supplier listens, challenges and explains trade-offs.
- A short action log with owners and dates.
- No pressure to treat an exploratory conversation as a final scope commitment.