Questions to Ask Software Development Clients
For freelance developers, agencies and in-house team leads working out what questions to ask a client for software development, before a price is named or an editor is opened. The list runs in the order a discovery conversation usually takes: the problem and the people who have it, the scope of the first release, the systems it has to fit into, the data it will hold, then budget, dates and sign-off, and last who owns and looks after the software once it is live.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
The problem
What problem should this software solve, and what happens today without it?
Why ask it
Clients tend to arrive describing screens. Bring them back to the trouble underneath, such as orders retyped by hand or customers who cannot check their own account, because that is what the build will be judged against. If the answer is a feature list, ask what each feature would stop from going wrong.
Who will use it, and what does each kind of user need to get done?
Why ask it
Get a list of roles with one job beside each: the dispatcher assigns routes, the driver confirms a drop, the owner reads a weekly total. Software for the client's own staff, for their customers, and for sale to other companies are three different builds, so settle which this is. Then ask to meet one real person from each role before you estimate.
Why build this now, and what would it cost you to wait another year?
Why ask it
The trigger is usually specific: a contract that demands it, a spreadsheet that broke, a supplier ending support for the old system. It tells you which part of the project is urgent and which was added because a budget finally existed. A client who would lose nothing by waiting may stall the first time a hard decision comes up.
How will you measure whether this software has paid for itself?
Why ask it
Push for something countable that they already track, such as hours spent on invoicing or the share of orders that need a phone call. Ask what the figure is today, since a result nobody measured beforehand cannot be shown afterward. Their answer belongs at the top of your proposal.
Have you looked at products you could buy or subscribe to, and where did they fall short?
Why ask it
The gaps they name are the true requirements, and sometimes they are small enough that an existing product plus one custom piece would do. Saying so can cost you a large job and win you a client who trusts your next quote. If nobody has looked, suggest they try two for a week before commissioning anything.
Could I watch someone do this job today, with the real spreadsheets, forms and emails open?
Why ask it
An hour at someone's desk turns up steps no manager mentions: the sticky note with the override code, the column everyone ignores, the phone call that settles odd cases. Ask for copies of the files they work from, with private details removed. For most small clients those files are the nearest thing to a specification.
Have you had software built before, and what became of it?
Why ask it
A past project that ran over or was abandoned explains much of how this client will behave, from insisting on a fixed price to checking in daily. Find out whether the old code, designs or database still exist and who holds them.
How many people will use it on day one, and what do you expect in two years?
Why ask it
Twenty staff on one office network and twenty thousand members of the public call for different architecture, testing and hosting bills. Ask what the forecast rests on: signed customers, or hope. Build for the number they can back with evidence, and tell them plainly which parts would need rebuilding beyond it.
Scope
Which features have to be in the first release, and which can wait for a later one?
Why ask it
Go through the wish list line by line and mark each must, later or maybe, with the client making the call out loud. When every line is a must, ask which ones the business could run without for three months. Price the first release alone and list the rest as a separate phase, so nothing is assumed to be included.
Take the single most important task. What does the user do first, and what happens at each step after that?
Why ask it
Draw it as boxes and arrows while they talk, and stop at every 'it depends'. Each of those is a branch you would otherwise discover in the middle of the build. One task traced end to end is a firmer basis for an estimate than twenty features named in a sentence each.
Is there an app or tool you already use that works the way you want this to?
Why ask it
Have them open it and point to the screen they mean. What they like is often one thing, such as a calendar you can drag jobs around on or a search box that finds anything, and one thing can be priced. Say so when the feature they admire took a large product team years, because it will not come cheaply in a first release.
What should each role be able to see and change, and do you need a record of who changed what?
Why ask it
Permissions cost little to design in at the start and a good deal more to add once the screens exist. Ask for the awkward cases: a manager covering another branch, a contractor who should see jobs but not prices. A change history is a feature in its own right, so find out who would read it and how far back it must go.
What should happen when something goes wrong: a payment fails, a record is entered twice, the connection drops mid-save?
Why ask it
Clients describe the day when everything works, and a great deal of the code handles the days when it does not. Pick the three failures most likely in their business and ask what a staff member does about each today. Their manual fix is frequently the rule the software should follow.
Which rules or calculations does it have to get exactly right, and who can explain them to me?
Why ask it
Pricing tiers, commission splits and scheduling rules tend to live in one person's head or in an old spreadsheet formula. Ask for that person's time and for ten worked examples with the correct answers, which later become your tests. Where a rule comes from tax or employment law, the client's accountant or adviser confirms it, not you.
What reports, exports or alerts should come out of it, and who acts on each one?
Why ask it
Reporting gets left to the end and then turns out to need data nobody stored. For each report, find out what decision it feeds and how often it is read. A plain export to a spreadsheet covers many of them for a fraction of the work, so offer that before a dashboard.
Is anything already written down or drawn, such as a specification, wireframes or screen designs, and who made them?
Why ask it
Read whatever exists before the next conversation, and check whether it is agreed or one person's draft. If there are no designs, settle who produces them: you, a designer the client hires, or a component library used as it comes. Design that nobody was assigned turns into development time nobody priced.
Does it have to work without a connection, or in more than one language, currency or time zone?
Why ask it
Each yes changes the foundations, which is why it belongs in discovery and not in a ticket six weeks in. Offline use means deciding what happens when two people edit the same record apart, so ask where staff actually lose signal. For a second language, the question is who translates and who keeps the wording current.
Does it have to meet an accessibility standard, and will anyone use it with a screen reader, enlarged text or a keyboard alone?
Why ask it
Which standard applies, if any, depends on the country, the sector and sometimes a customer's contract, so the client should check with whoever advises them and give you the answer in writing. Building for it from the first screen is much less work than repairing a finished product. Settle who tests it, and with which assistive tools.
What should this software leave alone, even though it could be made to do it?
Why ask it
Naming the edges protects both sides: bookkeeping stays in the accounting package, the public website is somebody else's job. Give the list its own heading in the proposal. When a new request arrives in month two, that is the page you both go back to.
Systems
Where does it have to run: in a browser, on iPhone and Android, on a desktop, or some mix?
Why ask it
Every platform added is more to build, test and keep updated, even when much of the code is shared. Ask what devices the users hold while doing the task and how old those devices are, since a warehouse scanner or a five-year-old tablet rules things out. A web app that behaves well on a phone is sometimes all that is needed, and it is worth saying so.
What software does the business already run that this will need to exchange data with?
Why ask it
Write down exact product names, versions and the owner of each account. Then ask which way the data flows and how fresh it must be, because a nightly file and a live two-way sync are very different amounts of work. Leave an integration unpriced until you have read the other system's documentation yourself.
For each of those systems, is there a documented API, and who can get me a test account?
Why ask it
What a vendor lets outside software do varies by product and by the plan the client pays for, so confirm it with the vendor instead of a sales page. A test account in hand before the quote lets you try the one call the project depends on. If the only way in is a file export, explain what that means for speed and reliability.
Will it take payments, send emails or texts, or show maps, and do you have accounts with any providers for those?
Why ask it
Each of these is somebody else's service, with its own fees, sign-up checks and rules on what you may send or store. Read the provider's current terms before you promise a feature that rests on it. For payments, ask the provider which setup keeps card numbers off the client's servers, and plan around that one.
Is there existing code this builds on or replaces, and may I read it before I estimate?
Why ask it
You are checking three things: whether it runs, whether it has tests, and whether anyone can still deploy it. Ask for repository access and an hour with whoever wrote it, if they can be reached. For a large codebase, propose a short paid review, since a guess here can throw the whole estimate off.
Is there a language, framework or cloud provider you require or rule out, and what is the reason?
Why ask it
A requirement backed by an in-house team who will maintain the result is one to respect. A preference picked up from an article is open to discussion, and the reason tells you which you are dealing with. If they have no view, lean toward what the next developer they hire is likely to know.
How will people sign in: a password of their own, the company's single sign-on, or a Google or Microsoft account?
Why ask it
Staff tools usually go more smoothly on the login people already have, and a leaver's access can then be shut off in one place. That takes cooperation from whoever runs the client's IT, so get that person's name now. For public users, ask who will deal with password resets and locked accounts.
What would an hour of downtime on a busy day cost you, and when are the busy days?
Why ask it
The answer sets how much to spend on monitoring, spare capacity and out-of-hours cover, which is the client's money to spend or save. It also tells you when never to deploy. A tool used nine to five by ten people needs far less than one taking orders at midnight.
Data
What information will the software hold, and is any of it personal, financial or health-related?
Why ask it
List the fields, not the categories: names, addresses, card details, dates of birth, medical notes. Sensitive fields change the hosting, the access controls and sometimes the rules that apply, which differ by country and industry. Go through whether each one is truly needed, since data you never collect cannot leak.
What existing records have to move into the new system, and when were they last cleaned up?
Why ask it
Request a full export, not a sample, and count rows, blanks and duplicates before you price. The mess only shows in the real file. Decide who fixes bad records, and whether the old system stays readable after the switch.
Which laws, industry standards or customer contracts govern how this data is handled, and who advises you on them?
Why ask it
This is the client's question to answer with their lawyer or compliance lead. Your part is to get the requirements in writing and build to them, so ask for that person's name and bring them in early. If the data is sensitive and nobody advises the client, recommend they find someone before you write the proposal.
Where does the data have to live: a particular country, your own servers, or a cloud account you already have?
Why ask it
Some clients are bound by a contract or a regulator on location, and some simply have an IT policy. Find out which, and who can confirm it. The answer narrows the hosting choices and belongs in the quote, because moving a live system later is a project of its own.
Will a customer, insurer or auditor of yours expect a security review before this goes live?
Why ask it
A large customer may send a long security questionnaire to anyone who handles its data, and the client does not always know one is coming. Ask to see a past one if it exists. An outside penetration test costs money and adds time to the schedule, so give it a line of its own.
If the system failed, how much work could you afford to lose: a day, an hour, nothing?
Why ask it
That figure decides how often backups run and what they cost. How long they could wait to be running again is a separate number, so get that too. Then agree who tests a restore and how often, since a backup nobody has restored from is only a hope.
During development, will I work with real customer records or a scrubbed sample?
Why ask it
A copy of live data on a developer's laptop is a risk the client may not have considered. Suggest a sample with names and contact details replaced, or fake records generated to match the real shape. If real data cannot be avoided, get the handling terms in writing before any of it is sent.
Budget and sign-off
What budget has been set aside, and does it cover design, testing, hosting and the first year of changes?
Why ask it
A range is enough to tell you whether to propose the full system or a smaller first release. Clients commonly budget for the build and nothing after it, so name the running costs early. If they will not give a figure, describe two or three sizes of project with rough prices and see which they lean toward.
What is the date you cannot miss, and what happens the day after if the software is not ready?
Why ask it
A trade show, a contract start or an expiring license is a real deadline, and scope has to bend to it. 'As soon as possible' is not one, and deserves a schedule based on the work. A client with no fallback for a slipped date needs a smaller first release.
Would you rather have a fixed price for a fixed scope, or pay for time and steer the work as we go?
Why ask it
Fixed price suits work that is well specified and unlikely to change. Paying for time suits a product still being worked out, though the client will want a cap or a regular budget check to feel safe. When the scope is too loose to price either way, a short paid discovery phase is the fair offer.
Who approves each release, and what will they look at before saying yes?
Why ask it
One named person with authority keeps a project moving. A committee, or an owner who appears only at the end, is where finished work gets reopened. Agree written acceptance criteria for each feature, so approval means checking a list and not judging by feel.
When I have a question about how the business works, who answers it, and how quickly?
Why ask it
Developers lose days waiting for answers about business rules. The contact should know the work in detail and be able to settle small things without calling a meeting. If that person already has a full job, build their reply time into your schedule and say that you have.
Who will test it before launch, and will they use real cases from their own work?
Why ask it
Your testing shows the code does what was specified, and theirs shows the specification was right. Ask for named testers, a block of time set aside, and a list of scenarios from an ordinary week. Testing left for spare moments tends not to happen, and the problems then surface in front of customers.
When you want something changed or added after work has started, how should we price and schedule it?
Why ask it
Changes are normal, so agree the routine before the first one arrives: a written request, an estimate, a yes or no, and a new date if one is needed. It is a far easier conversation at the start than in the middle of a disagreement. Settle how small a change has to be to skip the routine.
How would you like to see progress: a working demo every couple of weeks, a test link you can try, or a written update?
Why ask it
Working software shown regularly catches misunderstandings while they are cheap to fix. A client who wants to see nothing until the end is taking a bigger risk than they may realize, and it is fair to tell them. Fix the day and length of the demo now so it survives busy weeks.
After launch
Who will own the source code when the project ends, and what about libraries or tools I bring to it?
Why ask it
Each side walks in with an assumption: the client that everything built is theirs, the developer that their own components stay reusable. How ownership passes depends on the contract and on the law where you both work, so have it written down and looked over by whoever advises each side. Open-source parts carry their own licenses, and it helps to list the main ones.
Whose name will be on the hosting, domain, app store and third-party service accounts, and who pays those bills?
Why ask it
Accounts in the client's name, with you added as a user, mean they are never locked out of their own product. List every service the software depends on with its monthly cost, since usage fees for maps, messages or payments rise with the number of users. App stores generally publish from a developer account that takes time to set up, so have the client check the store's current requirements and open theirs early.
After launch, who fixes bugs, and for how long are fixes covered by the original price?
Why ask it
Agree what counts as a bug and what counts as a change, with an example of each. A stated period of included fixes, followed by a paid support arrangement, gives both sides something to plan around. Response out of hours is a separate service with a separate price.
Who will keep it up to date as operating systems, browsers, libraries and connected services change?
Why ask it
Software that nobody touches still ages: a phone update breaks a screen, a vendor retires an API version, a library gets a security fix. Put a yearly maintenance figure in front of the client before they sign for the build. If an in-house team will take over, meet them now and find out what they are comfortable maintaining.
When a user is stuck or locked out, who do they contact, and during what hours?
Why ask it
If the answer is you, that is a support contract and not a favor. Everyday requests such as resetting a password or adding a user can go to an admin screen run by the client's own staff, so scope one. Then find out who that admin will be.
How will people move over from the old way of working: everyone on one day, or one team at a time?
Why ask it
Starting with one team gives you real feedback while a mistake is still small. Find out whether the old system and the new one must run side by side, and for how long, because keeping two in step is extra work. Training needs an owner and a date as well.
What do you expect to want next, in the year after the first release?
Why ask it
You are not pricing these, only making sure today's design does not block them. A second country, a customer portal or a mobile app each points to a choice worth making now. Write them down as known future work, outside this price, so nobody later remembers them as promised.
If I became unavailable, what would another developer need in order to take this over?
Why ask it
A repository the client can reach, setup instructions that work on a clean machine, and a record of where everything is deployed. Offer these as deliverables with a price. Raising the subject yourself goes a long way with a first-time buyer who worries about depending on one person.
How to run discovery with a software client
Practical guidance for the conversation itself
Setting up the discovery conversation
Send the lookups ahead
Product names, user counts, account owners and existing documents are things the client has to go and find. Put those in a short written questionnaire a few days before you meet. Keep the meeting for the questions under The problem and Scope, where the first answer nearly always needs a second question.
Get three kinds of people involved
The person paying, a person who does the work today, and whoever runs the client's IT each hold a different part of the answers. If only the owner can attend, ask for an hour with each of the others before you estimate. Systems and Data questions put to someone who does not know produce confident guesses, so hold them for the person who does.
Scale the list to the job
A two-week internal tool does not need every question here. Take the first five, the first-release question under Scope, the question about connected software under Systems, and the ownership and bug-fix questions under After launch. A build that will run for months, or hold sensitive data, deserves the whole page spread over two or three sessions.
Use what exists before you meet
If there is a current system, a rival product or a spreadsheet doing the job, spend half an hour with it first. You will skip the questions it answers and arrive with better ones.
While the client is talking
Hold back the solution
Stay on the problem and the users for the first part of the meeting, even when you can already picture the database. A client who has been heard out on the problem is easier to talk out of a feature that will not help with it.
Translate as you go
Say 'a way for other programs to talk to it' before you say API, and 'the list of who can do what' before you say permissions. Jargon gets nods from people who have not followed, and an agreement reached that way comes apart at the first demo.
Draw it and turn the page around
Sketch the flow or the screen while they describe it, then show them. People correct a drawing more readily than a paragraph, and the corrections are the requirements you were missing.
Keep told and assumed apart
Run two columns in your notes: what the client said, and what you filled in yourself to close a gap. Read the second column back before you leave. Every line still unconfirmed is a risk sitting inside the estimate.
End on who owes what
Finish with a short list and dates: the export they will send, the vendor contact they will find, the day your proposal arrives. Discovery stalls on missing files far more than on missing ideas.
Turning the answers into an estimate
Write the scope back in plain words
Within a couple of days, send a page or two: the problem, the users, the first release, what is excluded, what is still unknown. Ask the client to mark it up. Put a price on it only after they have.
Price an unknown as an unknown
An integration you have not tested, or a codebase you have not read, should appear as a range or as a short investigation with a fixed fee. A single firm number laid over a guess is a promise you may end up paying for.
Charge for discovery when the brief is loose
If the first conversation leaves most of Scope unanswered, propose a small fixed-price phase that ends in a written specification, rough screens and a firm quote. The client gets a document they could take to any developer, and you stop estimating blind.
Show running costs beside the build price
Hosting, outside services, maintenance and support belong in the same document as the build, as yearly figures. A client who sees them at the start can plan for them. One who meets them for the first time at launch feels misled, whatever the contract says.
Where software discovery goes wrong
Quoting from a feature list
'Login, dashboard, reports, notifications' can be three weeks of work or six months. Until at least one task has been traced step by step, there is nothing solid to put a number on.
Playing the compliance adviser
You can describe what you have built before. Which privacy, payment or industry rules apply to this client depends on where they operate and what they do, and that answer has to come from their own adviser, in writing.
Leaving ownership and upkeep until launch week
Raised in the first meeting, who owns the code and who maintains it are practical questions with practical answers. Raised a week before launch, the same questions sound like the start of a dispute.
Designing around the favorite feature
The idea a client is most excited about is not always the center of the product. Check it against what they said under The problem before the architecture is built to serve it.
Agreeing to a date in the meeting
A deadline accepted before the work has been sized sets up the hardest conversation of the project. Say that you will come back with what can be ready by that date, and then do.