How to prepare for a software discovery call.

You don’t need documents, diagrams, or technical vocabulary — you need one hour and someone who knows the daily workflow. The best discovery calls are the ones where you simply describe your week honestly, and the worst preparation is trying to sound technical.

Here’s how to get the most out of that hour, whoever you have it with.

What a discovery call is actually for.

One hour has to answer three questions:

1. Where do the hours go? Which task eats the week, who does it, how often.
2. What has to stay? The tools you already run — accounting, webshop, planning — that any system must respect and connect to.
3. What does “better” look like in numbers? Hours back, faster response, fewer errors — something you can measure afterwards.

Everything else — architecture, technology, timeline — is the builder’s homework after the call, not your homework before it.

Bring these five things.

• One painful, concrete example. Not “our planning is chaotic” but “every Monday, Sanne spends four hours turning e-mails into the week’s schedule.” A concrete story beats an abstract summary every time.
• A list of your tools. Just the names: what you use for accounting, quotes, planning, communication. The names tell a builder in seconds what’s easy to connect and what isn’t.
• Who-does-what. Roughly which person touches the process at which step. Systems fail when the person actually doing the work was never asked.
• A number that matters. What would make this project obviously worth it? “Give us the Monday mornings back” is a perfectly good answer.
• The person who does the work. If possible, have them on the call. Ten minutes of them describing reality is worth more than any document — and they’re the ones who’ll use whatever gets built. Our process asks for exactly this, and nothing more.

What you can safely skip.

• Requirements documents. A written spec at this stage locks in guesses. The scope should come out of the conversation, in writing, afterwards.
• Technical vocabulary. Say “the thing where we retype orders into the spreadsheet,” not “an API integration.” Plain language transfers the problem more accurately.
• A budget number. Useful eventually, but the honest order is: scope first, then price the scope — not fit a scope to a number.
• Certainty. “We’re not sure this is automatable” is a fine opening line. Finding that out is what the call is for — and sometimes the honest answer is that it isn’t, which saves you months.

What should happen afterwards.

Judge any discovery call — ours included — by what lands in your inbox after it. You should receive something written: an assessment of the problem and a proposed scope, in plain language, with a real timeline attached. From there you can compare, sleep on it, or walk away — before you’ve committed to anything. What that looks like when it goes all the way is on our success stories page.

Red flags, for any vendor: a pitch instead of questions, no interest in your existing tools, a price before a scope, and jargon where plain language would do.

If you’ve read this far, you’re prepared. Book the hour, bring the painful example, and let the builder do the translating.