Andriy runs a growing logistics business. Spreadsheets worked until they did not. He booked a discovery call with a software team — thirty minutes on the calendar — and suddenly realised he is not sure what to say. Should he bring a full specification? A mood board? A competitor list the length of a novel?
Discovery calls fail quietly when both sides leave polite but unclear. The vendor guesses scope; the founder feels unheard. Nobody says the call went badly — there is no argument, no red flag — but three weeks later the proposal that lands in the founder's inbox is generic, the estimate is a wide range, and the next call starts from zero again. A short preparation pass fixes most of that, and it costs less time than most founders assume.
Start with the outcome, not the feature list
Replace "we need an app with dashboards, notifications, and AI" with one sentence about what must be true in three months:
- "Dispatchers assign routes in under two minutes instead of twenty."
- "Clinic patients book and pay without phoning reception."
- "Sales reps see live stock while visiting retailers."
That sentence becomes the anchor for every follow-up question. If a proposed feature does not serve it, it belongs in a later release — or not at all.
This matters more than it sounds like it should, because feature lists are where discovery calls go to die. A list of desired functionality tells a vendor what you have seen other products do, not what your business actually needs. Two founders can hand over near-identical feature lists — auth, dashboard, notifications, payments — and be building entirely different products underneath, because one needs to cut a manual process from twenty minutes to two and the other needs to stop losing customers at checkout. An outcome sentence forces that difference to the surface immediately, before anyone has spent time designing a screen nobody asked to solve the real problem.
It also gives the vendor something to push back on, which is useful. A good engineering team should be able to look at your outcome sentence and say "that's achievable in six weeks with a thinner version" or "that requires an integration we should scope first." A feature list rarely invites that kind of scrutiny — it just gets estimated, feature by feature, which is how founders end up with a quote for a system nobody actually needed built in full.
Name your users and their worst day
Generic personas waste time. Describe one primary user and the moment your product saves them:
Who are they? What triggered the need today? What do they do right now instead (WhatsApp, Excel, paper)?
Teams that answer this clearly get realistic estimates. Teams that skip it often discover mid-build that "admin" and "end customer" need completely different flows.
The failure mode here is subtle and expensive. It is easy to describe your product from the inside — as a system with roles and permissions — and forget that the actual person using it on a Tuesday afternoon has a phone signal problem, three other tabs open, and thirty seconds of patience. Naming the worst day, not the ideal day, is what makes a scope realistic. "Dispatcher assigns a route" is an abstract requirement. "Dispatcher is on the phone with an angry customer, needs to reroute a driver in under a minute, standing at a warehouse counter with one hand" is a design constraint. The second version changes what gets built first, and often changes the platform choice too.
It is also worth being honest if you have more than one user type that matters equally — an internal ops team and an external customer, say. That is fine, but say it out loud rather than letting the vendor assume a single flow. The point of naming users precisely is not to produce a polished persona document; it is to prevent the team from designing for an imagined "average user" who does not resemble anyone who will actually open the app.
Bring constraints early — they are gifts
Budget range, target launch window, must-have integrations (Stripe, HubSpot, legacy ERP), and compliance (GDPR, PCI, health data) are not awkward topics. They are filters that prevent wasted design work.
You do not need exact numbers. "We need something live before Q4 conference season" or "We cannot store card data ourselves" is enough to shape architecture on the first call.
Founders sometimes withhold constraints out of a vague instinct that a wide-open brief will get a more ambitious answer, or that naming a budget invites the vendor to quote up to it. In practice the opposite happens. Without constraints, a vendor has to design for the maximum plausible version of your product, because they have no signal for what to cut. That maximum version is slower to scope, more expensive to estimate honestly, and usually further from what you actually need for a first release. A stated constraint — even an approximate one — lets a competent team immediately rule out entire categories of architecture and start proposing something you can actually ship.
The same is true for compliance. Saying "this touches health data" or "we need to be PCI-compliant for card storage" on the first call, rather than the fifth, changes the technical shape of the whole build — sometimes it means using a hosted payment provider instead of building custom checkout flows, sometimes it means a different hosting region entirely. Finding this out after a design is half-built is one of the more common and avoidable sources of rework in software projects.
Show what you already have
Existing materials accelerate discovery:
- Wireframes or Figma links — even rough
- Current site or app URLs
- Export of the spreadsheet that runs the business today
- List of what broke last quarter
Ugly truth beats polished fiction. Engineers learn more from a messy operational workflow than from a slide deck that says "seamless experience."
The spreadsheet in particular is underrated as a discovery artifact. A working spreadsheet, however chaotic, encodes real business logic — the columns nobody uses, the ones that get a manual override every month, the tab that only one person understands. That is more informative than a requirements document, because it shows what the business actually does rather than what someone remembers or wants to claim it does. If a founder is embarrassed by how messy their current process looks, that is usually a sign the vendor needs to see it, not a reason to hide it.
Ask for explicit non-goals
The best discovery outputs include what v1 will not do. No multi-language, no custom reporting builder, no native desktop app — written down and agreed.
Non-goals protect both sides. Founders avoid scope creep; vendors avoid quoting a product that was never meant to ship in phase one.
Non-goals are also where most disagreements later in a project actually originate, because they were never disagreements — they were assumptions that diverged silently. A founder assumes multi-language support is obviously part of "launch" because their market is bilingual; the vendor assumed it was a phase-two nice-to-have because nobody said otherwise. Neither side was wrong, exactly, but the gap surfaces in week six as a scope conversation nobody wanted to have. Writing non-goals down at the first call, even in rough form, converts a future argument into a present-tense decision that both sides can revisit deliberately if priorities shift.
What you should leave with
A useful first call ends with shared understanding, not a fixed price on the spot. Expect:
- Restated problem in the vendor's words — you should nod, not correct every line.
- Suggested first slice — a thin vertical path, not the entire roadmap.
- Open questions — data model unknowns, integration access, design ownership.
- Next step — follow-up workshop, written summary, or a short written proposal with assumptions listed.
If those four are missing, ask for them. Clarity is the product of discovery; code comes later.
A fixed price on a thirty-minute call is worth treating with suspicion rather than relief. It usually means one of two things: either the vendor is quoting a template they use for every client regardless of what you actually described, or they are padding the number heavily to cover the unknowns they have not asked about yet. Neither is a good sign. A team that instead proposes a first slice — a narrow, buildable piece of the product that proves the riskiest assumption — is telling you they intend to learn from real usage before committing to the rest of the roadmap. That is a slower-sounding answer on the call, and a faster path to a working product in practice.
Common mistakes that stall a first call
A few patterns show up often enough to name directly:
- Over-preparing the wrong thing. A forty-page requirements document is not preparation — it is a substitute for the conversation the call is meant to have. Ten minutes of the four sections above beats hours of speculative specification.
- Treating the call as a pitch. Founders sometimes present their idea as a finished vision rather than a problem to be solved together. The more useful posture is closer to a working session: bring the real constraints, including the ones that make the product look less impressive.
- Skipping the "why now." What changed that made this the month to solve it? A funding round, a churn spike, a manual process that finally broke at scale — the trigger tells a vendor how much runway you actually have, which affects both scope and sequencing.
- Not naming who owns decisions. If three stakeholders need to sign off on design direction, say so up front. Discovering it in week four is far more expensive than mentioning it in minute five.
None of these require extra work to avoid — they require saying the true, sometimes unflattering thing out loud instead of the tidy version.
At Stereasoft we treat discovery as part of delivery, not a sales ritual. The founders who prepare a single outcome, one user story, and honest constraints almost always move faster — whether they build with us or not.