What a Discovery Call With a Software Studio Should Actually Cover

A lot of "discovery calls" with software vendors are really just sales calls wearing a different name — fifteen minutes of small talk before a generic pitch. A genuinely useful discovery call should leave both sides knowing whether this is a good fit, before any contract or quote enters the conversation. The questions that actually matter, in our experience: what's the workflow this replaces, and who's doing it manually today? That tells us more about scope than any feature list. What happens if this project is six weeks late — is there a hard external deadline, or is that just discomfort? That tells us how to plan the build and where the real risk sits. And what does success look like in three months, in a number you can point to — fewer support tickets, faster lead response time, a specific revenue figure? Vague success criteria almost always lead to scope creep later, because without a number to aim at, "done" keeps moving. We also ask about what's already been tried. If a team attempted something similar before and it stalled, understanding why matters more than the technical spec — sometimes the previous attempt failed for organizational reasons (no one owned adoption) rather than technical ones, and no amount of better code fixes that on its own. What we're explicitly trying to avoid is a one-hour call that ends in an enthusiastic "yes" to everything, because that usually means neither side asked the hard questions. A good discovery call sometimes ends in "this isn't a great fit for us" — and that's a better outcome for everyone than six months into a project discovering the same thing the hard way.