Choosing a Partner
Engineering Practice6 min read
Questions to ask a client when developing software: the discovery list that prevents rework
Most software projects go wrong in the first two weeks, in the questions nobody asked. Here are the requirements-gathering questions to ask a client, grouped by what they protect you from.
Working on something like this?
Get an estimateThe short version
- Ask about the problem and the people before the features. A requirement list written without them is a wish list.
- The questions that save the most money are about integrations, data, and who can say yes. Features are the easy part.
- Ask what has been tried before, and what the client is afraid of. Both reveal constraints no document contains.
- Write the answers down and play them back. Half the value of discovery is the client seeing their own answers in black and white.
If you build software for other people, the quality of your questions sets the ceiling on the quality of the result. Ask too few and you build the wrong thing quickly. Ask the wrong ones and you collect a long list of features that tells you nothing about why the client needs them.
This is the list we work from. It applies whether you are an agency starting a client project, an internal team building for another department, or a business implementing new software and wondering what its vendor should be asking you. (If you are the client looking for the opposite list, see our questions to ask a software development agency.)
Start with the problem, not the feature list
Clients arrive with solutions. “We need an app with a dashboard and push notifications.” That is a design, and it may be the right one, but it is not a requirement until you know what it is for.
- What problem are we solving, and how do you know it is a problem? What is it costing you today, in time, money, or customers?
- What happens if we do nothing for a year?
- How will we know, six months after launch, that this worked? What would you measure?
- Who asked for this, and who will be unhappy if it ships?
- Is there a date this has to be live by, and what is driving that date?
Ask about the users who are not in the room
The person briefing you is rarely the person who will use the software every day. Their idea of the workflow is a summary of someone else's job.
- Who will use this, in what roles, and roughly how many of each?
- Can we speak to two or three of them directly, before we design anything?
- What do they do today instead? What spreadsheet, email thread, or manual process does this replace?
- What do they like about the current way of working? What must not get worse?
- What devices and connections will they be on? A warehouse tablet and an office desktop are different products.
Questions to ask about scope and decisions
Scope disputes are almost always decision-making disputes in disguise. Settle who decides, and how change is handled, before the first line of code.
- Who is the final decision-maker on scope, design, and acceptance? Is that one person or a committee?
- Who else needs to sign off: legal, security, finance, a parent company?
- What is explicitly out of scope for this phase?
- How do you want to handle new requests once we are underway? Swap for something of equal size, add budget, or defer?
- Is the budget fixed, flexible, or a ceiling someone has to defend upward?
The answers shape the commercial model too. A client who wants fixed scope and a fixed price but expects to change their mind is describing something that does not exist; see fixed price versus time and materials for how to have that conversation.
Questions to ask when implementing new software: integrations and data
This is the section that changes estimates the most, and the one clients volunteer least, because they do not know it matters. Whether you are building from scratch or implementing a packaged product, the new system has to live alongside the ones already there.
Ask to see the data and the integration documentation during discovery, and try the credentials. A description of an API is not an API. This single habit is behind most of the reasons estimates double.
Constraints that nobody mentions until they hurt
- What security, privacy, or compliance rules apply: HIPAA, PCI, SOC 2, GDPR, accessibility standards, procurement requirements? Who checks?
- Is there an approved cloud, a required vendor, or a technology that is off limits?
- What happens when it fails? Who is affected, and how quickly must it recover?
- How much load is expected, including peaks such as month-end, seasonal sales, or deadlines?
- Who will run and maintain it after launch, and do they have the skills for the stack we are about to choose?
The last of those matters more than clients expect. Software built on a stack the client cannot hire for becomes a dependency on the builder. If you are unsure how to weigh it, our guide to build versus buy covers the trade-off.
Ask what has been tried before
Few clients are starting from nothing. Someone has usually tried a tool, a previous vendor, or an internal build, and it did not stick. The reasons are free information.
- What have you tried already, and why did it not work?
- Have you worked with a development partner before? What went well and what did you wish had been different?
- Are there any existing designs, prototypes, or documentation we should read?
- What are you most worried about on this project?
The most useful answer in a discovery workshop is often the reply to “what are you worried about?” It is the one question that gets people to say the risk out loud.
Questions about delivery and working together
- Who will be our day-to-day contact, and how much of their week can they give this?
- How quickly can you give feedback on a demo? Slow feedback is the most common cause of late projects.
- Who needs to see progress, in what format, and how often?
- Who will do user acceptance testing, and when are they available?
- How do you want to launch: all at once, to a pilot group, or in phases?
A client who cannot commit time to reviews is telling you about the schedule. Better to agree a realistic review cadence than to plan around reviews that will not happen. It also feeds directly into how long the project will take.
How to run the conversation
1
Send a short pre-read
Share the headline questions a few days ahead so the right people turn up with the right answers, rather than guessing in the room.
2
Talk to users separately
People answer differently with their manager present. A fifteen-minute call with someone who does the job is worth an hour of stakeholder opinion.
3
Ask for artefacts, not descriptions
Request real spreadsheets, screenshots, API docs, and sample data. What people show you is more accurate than what they remember.
4
Write it up and play it back
Return a short document of what you heard, what you assumed, and what is still open. Corrections at this stage cost nothing.
5
Turn the open items into the plan
Every unanswered question is either a risk to price in or a task for discovery. Do not let them sit as unspoken assumptions. A scoped MVP starts from exactly this list.
A short version to keep
If you remember nothing else, ask these
- What problem is this solving, and how will we know it worked?
- Who will actually use it, and can we talk to them?
- What is the one thing the first release must do?
- What does it have to connect to, and who owns those systems?
- Who makes the final call, and who else has to approve?
- What have you tried before, and what are you worried about?
If you are planning a build and would like a second pair of eyes on your discovery questions, or a team to run the discovery with you, talk to us. We start with the questions, not the quote.
Working through this on a real project?
Tell us what you are building. You will get a scoped estimate and an architecture you own, not a capability deck.
Common questions
Start with the problem and how success will be measured, then who will use the software and whether you can speak to them. Follow with scope and who makes decisions, the systems and data it must integrate with, security and compliance constraints, what has been tried before, and how the client will take part in reviews and testing during delivery.
What problem are we solving, what happens if you do nothing, how will you know it worked, who will use it, what is the one thing the first release must do, who decides on scope, and what are you worried about. These open the conversation without turning it into a technical interrogation.
Which existing systems it must connect to and who owns them, what data has to be migrated and what condition it is in, which system is the source of truth, what reports the business already depends on, what compliance rules apply, who will run it after launch, and how the rollout should be phased.
There is no fixed number, but a single session with dozens of questions produces tired, shallow answers. Spread the questions across several shorter conversations, prioritise the problem, users, integrations, and decision-making first, and leave detailed technical questions for the people who own those systems.
Work backwards from the problem. Ask what it costs today, who is affected, and what one outcome would make the project worthwhile. Talk to the actual users, look at the spreadsheets and processes they use now, and propose a small first release that tests the biggest assumption rather than asking the client to specify everything up front.
Yes. Ask whether it is fixed, flexible, or a ceiling, and what is driving it. A budget range lets you propose a scope that fits rather than quoting something that will be rejected, and it shows early when expectations and cost are far apart. If a client will not share one, offer ranges for two or three scope options and see which they gravitate to.
Which systems the software must connect to, who owns them, whether you can get credentials and documentation during discovery, how much existing data must be migrated and in what format, and which system is the source of truth for each type of record. Ask to see real samples rather than accepting a description.
Write them up and send them back to the client, separating what you heard, what you assumed, and what is still open. The client corrects what you misunderstood, and the open items become either priced risks or tasks for the discovery phase.