- A software discovery call is a first conversation about a business problem, not a sales pitch and not a technical exam. You can start with a problem. You don't need a specification.
- The call's job is to help you decide what's worth doing next. Sometimes that's a new build. Often it's something smaller: connecting what you already have, fixing a handoff, or checking one assumption first.
- The questions matter more than the pitch. Asking what you're actually trying to achieve can turn a request for a comprehensive integration into a simple middleware connection that costs far less to build.
- You should leave with five things: a shared understanding of the problem, a clearer picture of success, a preliminary direction, the open questions that still need checking, and an agreed next step.
- A call isn't a full discovery phase. Some projects can be estimated right away. Others need a short investigation first, and a good partner will tell you which one you have.
Direct answer: During a software discovery call, a development team asks about your business goal, your current workflow, the tools you already use, the people affected, and your timing and budget. The goal is to understand the real problem before recommending a solution. You should leave with a shared understanding of the problem, a clearer definition of success, a preliminary recommended direction, a list of questions that still need answers, and an agreed next step.
Most of the people who book a call with us don't open with a spec. They open with a frustration. Someone on the team is re-entering the same order in three places. A spreadsheet has quietly become the system everyone depends on. The software that worked at twenty customers is struggling at two thousand. Or there's an idea for an app and no clear sense of where to start.
That's exactly the right way to begin. I've sat in a lot of these first conversations, and the most useful ones never start with "here's what to build." They start with "here's what's getting in the way." The building part comes later, once everyone agrees on what's actually worth building.
That order matters more than it might seem. When McKinsey and the University of Oxford studied more than 5,400 large IT projects, schedules turned out to be the smaller problem. Value was the bigger one:
These are big projects, far larger than most of the work we do. But the pattern is familiar at any size. A project can be delivered roughly on schedule and still miss the point. A good discovery call is the cheapest place to make sure it doesn't. (The same study notes that software projects carry the highest risk of cost and schedule overruns of any project type it reviewed.)
01 — The definition
What Is a Software Discovery Call?
A software discovery call is a first conversation between a business and a development team to understand a problem, the systems and people around it, and what a successful outcome would look like, before anyone recommends a solution or writes code.
It's worth separating the call from something people often confuse it with:
- Length: one conversation, usually 30 minutes
- Purpose: understand the problem and agree on a sensible next step
- Output: a shared picture of the problem, a preliminary direction, and open questions
- Cost at Virgo: free, no obligation
- Length: a defined engagement, often weeks
- Purpose: investigate users, systems, data, and constraints in depth
- Output: evidence for a go, change, or stop decision, plus a plan detailed enough to commit to
- When it's needed: when key assumptions can't be checked in a conversation
The U.K. government's Service Manual describes the purpose of that deeper phase plainly: "Before you commit to building a service, you need to understand the problem that needs to be solved." A discovery call applies the same thinking in miniature. It doesn't replace a full investigation. It tells you whether you need one.
02 — The conversation
What Happens During a Software Discovery Call?
Every call is different, but the ground we cover is fairly consistent. We'll want to understand:
- The business goal. Not the feature you want, but what should be different for your business once it exists.
- The current workflow. How the work actually happens today, including the workarounds nobody wrote down.
- The tools you already have. Your CRM, store, billing system, spreadsheets, and anything else involved.
- The people affected. Who does the work, who depends on the result, and who has to approve a change.
- Timing, budget, and constraints. Deadlines, seasonal pressure, compliance needs, and what a realistic investment looks like for you.
The questions are where the real work happens. A good question isn't there to fill time or to qualify you as a lead. Its answer should be capable of changing the recommendation. Here are five we find ourselves coming back to, and what each one is designed to uncover:
| Question | What it helps clarify | How the answer can change the plan |
|---|---|---|
| "Can you walk us through one recent example?" | Where the workflow actually breaks down | A real example often moves the problem somewhere other than where the request pointed |
| "Which system owns this information?" | Whether the issue is data ownership or a missing connection | A "new platform" request can become an integration between tools you already pay for |
| "What already works well?" | What should be preserved | Keeps a fix from breaking the parts your team relies on, and keeps scope honest |
| "What must improve first?" | The priority for a first release | Turns a long wish list into a smaller first step that still delivers value |
| "What do we still need to verify?" | The assumptions that need checking before a reliable commitment | Separates what can be estimated today from what needs a short investigation first |
These aren't a script. They're the kinds of questions that tend to matter most, and the follow-ups depend entirely on your answers.
03 — A worked example
How Can One Question Change the Recommended Approach?
Here's a real example from our own work, anonymized, and it's one of my favorites because the client ended up spending less than they planned to:
- The original request. A client came to us wanting a more comprehensive API integration with their CRM.
- The questions. On the discovery call, we didn't start with endpoints or data fields. We focused on what the client was trying to achieve, and what the integration actually needed to do to get them there.
- What the answers revealed. The goal didn't require a comprehensive integration. The tasks that mattered were a much narrower set than the original request covered.
- How the recommendation changed. We recommended a very simple middleware connection instead. It minimized development time and the cost to implement, and it still accomplished the tasks and the goal, without the added cost of the larger build.
The original request wasn't wrong. It was a reasonable way to describe the need before anyone had looked closely at it. Discovery's job is to trace a request back to the outcome behind it, so you only pay for what actually gets you there.
Another example from our team shows the same thing from a different angle. When a client needed an already-lean estimate cut by another 28%, Senior Engineer Shane Taylor went back to them with one question: what absolutely has to work on launch day? That question reshaped the scope, and the client launched on the smaller budget. We tell the full story in The Best Thing a Software Engineer Can Do for Your Budget Is Say No. And for why questions asked early are so much cheaper than rework later, Izzy Hymas makes the case in Slow Down to Build Faster.
04 — The takeaways
What Should You Leave a Software Discovery Call With?
A discovery call is worth your time if you walk away with more clarity than you brought, whether or not you ever hire us. Here's what that clarity should include:
Five things you should leave the call with
- A shared understanding of the problem: stated in plain language that both you and the development team would agree with
- A clearer description of success: what will be measurably different for your business, not just which features will exist
- A preliminary recommended direction: build, integrate, configure what you already own, or wait, along with the reasoning behind it
- The questions still requiring investigation: the assumptions that need checking before anyone can commit to a reliable estimate
- An agreed next step: what happens next, who's responsible for it, and whether it has a cost
What we put in writing. After a discovery call with Virgo Development, we send a written summary of our recommendations, so the conversation doesn't live only in someone's notes. When the scope is clear enough, that includes an honest cost estimate. When it isn't, we'll say so, and tell you exactly what needs to be confirmed first and what it would take to confirm it. We'd rather give you a reliable number a little later than a confident guess today. (If you're comparing partners, an instant fixed quote with no questions asked is one of the red flags we cover in how to choose a software development company.)
And sometimes the honest recommendation is that you don't need custom software at all. If a tool you already own can solve most of the problem, you should hear that on the call.
05 — Preparation
How Should You Prepare for a Software Discovery Call?
You don't need technical knowledge, a requirements document, or a finished idea. A little preparation does make the conversation go further, though. If you can, bring:
- One recent, specific example of the problem. "Last Tuesday, an order came in and here's everything that happened to it" is worth more than a general description.
- A list of the systems involved. Names are enough: your CRM, store, billing platform, scheduling tool, and the spreadsheets that fill the gaps.
- Who's affected. The people doing the work, and the people who rely on the result.
- Known constraints. A deadline, a busy season, a compliance requirement, or a budget range, even a rough one.
- Optional extras. Screenshots, a quick sketch of the workflow, or examples of software you like. Helpful, never required.
If you're starting from an idea rather than an existing process, I Have an Idea for an App. What Do I Do Next? walks through what's worth thinking about first. And if any of the vocabulary feels unfamiliar, our plain-English guide to software terms is a good warm-up.
06 — The next step
What Happens After a Software Discovery Call?
The call ends with a decision about the next step, chosen to fit what we learned. In practice, it's usually one of these:
- A proposal. When the problem and scope are clear, we put together a written plan and estimate.
- A review of an existing system. When the right move depends on what your current software can and can't do, we look before we recommend.
- An integration feasibility check. When the answer depends on whether two systems can exchange the data you need, we confirm it with their APIs and documentation first.
- A defined discovery engagement. When the open questions are too big to answer in a conversation, we scope a deeper investigation with its own clear deliverables and cost.
- No project, yet. Sometimes the best next step is yours alone: a process change, a setting in a tool you already own, or waiting until the timing is right.
Whatever the next step is, you should know it before the call ends, along with who owns it and whether it costs anything. No mystery follow-ups. If you're already wondering what a full project might cost, How Much Does It Cost to Build a Custom Software Application in 2026? explains what drives the number, and why scope has to come first.
When the next step is a build, that's what our custom software development team does. When it's a connection between systems you already have, it's our system integration work. For a sense of how a long-term engagement grows out of that kind of listening, see how we built software tailored to Berry's Manufacturing.
07 — Common questions
Quick Answers
Do I need technical knowledge for a software discovery call?
No. You bring knowledge of your business, your customers, and the problem. The development team brings the technical questions. Plain language is not just fine, it's usually better, because it describes what actually happens instead of what someone thinks the software should do.
Can you help if I already know what I want built?
Yes. A clear idea is a great starting point. We'll still ask about the goal behind it, the systems around it, and what must work first. Sometimes that confirms the plan. Sometimes it finds a smaller first version or a risk worth checking before you commit.
Is the discovery call free, and how long does it take?
At Virgo Development, discovery calls are free and come with no obligation. The standard call is 30 minutes, which is almost always enough to understand the problem and agree on a next step, and you'll talk with members of the engineering team, not a salesperson.
Will I receive a written plan or estimate after the call?
You'll receive a written summary of our recommendations. When the scope is clear enough, it includes a cost estimate. When important questions are still open, we'll explain what needs to be confirmed first and what that would involve, rather than guessing at a number.
When is a deeper discovery phase necessary?
When the answer depends on things a conversation can't confirm: whether two systems can actually exchange the data you need, how an existing codebase is built, how real users behave, or what regulations apply. In those cases, a defined discovery engagement with its own scope and cost is the responsible next step.
08 — Let's talk
Start With What's Getting in the Way
Tell us what you want to accomplish, what's getting in the way, and what you already have in place. We'll ask good questions, give you an honest read, and help you find a practical next step, even if that step doesn't involve us.
Book a Discovery Call with me and the team, or email [email protected]. Discovery calls are free.
Jamie Lords ↗ LinkedIn is CEO of Virgo Development and teaches Business and Marketing at Southern New Hampshire University. Since 2005, Virgo Development has helped businesses decide what's worth building, then built, integrated, and supported it, from a 100% U.S.-based team with headquarters in St. George, Utah. Sources: Michael Bloch, Sven Blumberg, and Jürgen Laartz, "Delivering large-scale IT projects on time, on budget, and on value," McKinsey & Company (October 2012); MuleSoft, 2025 Connectivity Benchmark Report (January 2025); GOV.UK Service Manual, "How the discovery phase works" (last updated June 2021). The worked example is a real Virgo Development project, anonymized. The discovery questions are examples of the kinds of questions we ask, not a fixed script. Compiled October 2026.