How to Prepare for a Software Discovery Call

Bring the problem, not the solution. A discovery call that starts with a feature list produces a quote for that list, which may or may not solve anything.

Four things make a thirty-minute call productive. None of them is technical.

What breaks today

Describe the current process, including the parts done in a spreadsheet, over the phone, or in someone's head. Where does it fail, how often, and what does each failure cost in time or money?

This is the single most useful input, and it is the one most often skipped in favour of describing the software someone imagines. A vendor who understands the failure can usually propose something smaller and better than what you were about to ask for.

Who actually uses it

Name the people. Not "users", but the three roles who will touch this daily, what device each has, and how technical they are.

Software for a warehouse supervisor on a shared Android phone is a different product from the same features aimed at an accountant on a desktop. This single detail changes architecture, interface, and cost.

What success looks like in six months

One or two sentences, ideally measurable. "Orders processed without a phone call." "Month-end close in a day instead of a week." "Stock counts that match reality."

Without this, every feature seems equally important, and a project with no priority order runs until the budget ends rather than until it is done.

Constraints you already have

The systems it has to talk to, the deadline that is real, the budget range, and anything legal or contractual. Constraints are not bad news for a scoping call. They narrow the options, which is exactly what you want in thirty minutes.

Say if you have an existing system and who built it. Replacing something is a different job from starting fresh, and finding out on the third call wastes both sides' time.

What to ask in return

Turn the call around at the end. Who will lead the project and will you talk to them directly? What has this team built that is closest to your problem, and can you see it running? What in the scope worries them most? When does the source code become yours?

That third question is the useful one. A vendor who names a specific risk has thought about your project. A vendor who says it is all straightforward has not, or is not telling you.

What happens after

You should expect a written proposal covering scope, timeline, price, and the assumptions the price rests on. The assumptions are the part to read carefully, because that is where the difference between two quotes usually hides.

Our own process: a reply within one business day, a thirty-minute call, and a written proposal within three business days of it. If a vendor cannot tell you their turnaround, that is itself informative.