How to Prepare for a Custom Software Discovery Call — Without a Finished Spec

A lot of small business owners put off a discovery conversation about custom software or AI automation because they feel like they need to show up with a finished spec — a document laying out exact requirements, screens, and features. A good discovery call doesn’t need that level of detail. Waiting for full clarity usually just delays a conversation that would have sharpened the thinking faster than working alone. What actually moves a discovery call forward is a handful of concrete, specific pieces of information about how the work happens today. None of it requires design skills or technical language — it requires knowing your own process.

Put this preparation packet together beforehand.

1. A Walkthrough of the Process as It Actually Happens

Describe the real process, including the parts that are a little embarrassing. Write down or be ready to walk through, step by step, what happens from trigger to completion: what starts it, who touches it, what tools they use at each step, and where it ends. If the process has different paths depending on circumstances (a rush order versus a standard one, a new client versus a repeat one), note the branches. If you genuinely don’t know the full path because different people do it differently, say so — that usually means the first project deliverable is standardizing the process before automating it.

2. The Tools Currently in Play

List the software, spreadsheets, and systems the process touches today, even the ones held together with duct tape — the shared spreadsheet no one wants to touch, the tool you’re paying for but barely use, the step still done by email because nothing else does it. Note which of these have any kind of integration or API today, even if you don’t know the technical details; “I think it can connect to other things but we’ve never tried” is a fine answer. This list tells us what a new system needs to work alongside or replace.

3. Specific, Recent Examples

“Sometimes things get missed” is hard to design against. “Last Tuesday, an order came in through the website but nobody saw it until Thursday because it goes to an inbox only one person checks” is something concrete to solve. Bring two or three real, recent examples of the problem showing up — what happened, why, and what it cost (time, a lost customer, a mistake that had to be fixed). Real examples surface edge cases a generic description never will.

4. Rough Volume and Frequency

You don’t need exact analytics. Approximate numbers are enough to tell the difference between a problem that needs a light-touch fix and one that justifies a more substantial build: how many times a day or week does this happen, how many people are involved, and how much time does it currently take per instance. “About 30 a week, taking maybe 15 minutes each” is plenty of precision to start with.

5. Who’s Involved and Who Decides

Name the people who touch this process day to day, and who has the authority to approve changing it. A process that only one person understands and no one else can weigh in on is a different kind of project than one that affects a team with competing opinions about how it should work. If there’s a person likely to resist a change to their current workflow, naming that upfront saves time later.

6. Constraints That Are Actually Fixed

Budget range, timeline pressure (is there a deadline tied to something real, like a seasonal peak or a contract renewal), and anything that’s non-negotiable for legal, compliance, or client-relationship reasons. Vague constraints (“keep it affordable,” “not too complicated”) are less useful than specific ones (“this needs to be usable by someone with no technical background” or “this data can’t leave the country” or “we can’t add another monthly subscription right now”).

7. What “Better” Actually Looks Like to You

Describe the outcome you want. Fewer missed leads, faster turnaround, less time spent on data entry, fewer errors in a specific type of record. A feature list can wait. A clear picture of what success looks like, even described informally, gives a discovery conversation something concrete to design toward and gives you something concrete to measure against later.

What You Don’t Need to Bring

You don’t need a requirements document, wireframes, a list of desired features, or technical vocabulary. You don’t need to have already decided whether the answer is off-the-shelf software, custom software, or an AI-driven automation — a discovery conversation is for sorting that out. See our piece on custom AI software vs. off-the-shelf tools if you want a head start on that framing, but it’s not required reading beforehand.

Decision Criteria for Whether You’re Ready for a Discovery Conversation

• Can you describe the current process to someone who’s never seen it? If yes, you’re ready — polish isn’t required.
• Do you have at least one or two concrete, recent examples of the problem? Specifics beat generalities every time.
• Is there someone with the authority to say yes to a next step? A discovery conversation without a decision-maker in the loop tends to stall afterward, often because nobody could act on the ideas.

Risks

The most common way discovery conversations lose value is when the information brought to them is aspirational rather than actual — describing how the process is supposed to work instead of how it really works, or how you wish volume looked instead of the real number. A build based on an inaccurate picture of the current state produces a system that doesn’t fit, no matter how well it’s engineered.

Human Review Boundary

A discovery conversation should surface options and trade-offs. It should not hand down a single locked-in answer on the spot. Decisions about scope, budget, and approach deserve a follow-up where you’ve had time to sit with what was discussed.

If you’ve got the packet above roughly together — even in your head rather than on paper — that’s enough to start. Our custom software and AI consulting work begins exactly there, or if you’d rather get a structured read on where your business stands before that conversation, an AI readiness audit is built for that.