Skip to content
lazy devs
5 min readLazy Devs

What to expect in a discovery call with a dev agency

Nervous about that first call with a development agency? Here is exactly what we ask, what to bring, and what you should walk away with, so you can reach out without the dread.

You have an idea, or a half-built thing, or a deadline breathing down your neck. You found an agency that looks like it knows what it is doing. And now you are hovering over the contact form, talking yourself out of it, because you are not sure you know enough to have the conversation. What if they ask something technical you cannot answer? What if it is forty minutes of polished sales talk and a price you cannot read?

We do these calls every week, and the worry is almost always misplaced. A discovery call is not an exam, and it is not a pitch. It is two parties figuring out whether there is a real project here and whether we are the right people to build it. Here is exactly what happens, so the only thing left to decide is whether to hit send.

What it actually is (and is not)

A discovery call is a conversation, not a presentation. The whole point is for us to understand your problem well enough to tell you something useful, and for you to get a feel for how we think before any money changes hands. Thirty to forty-five minutes, usually. No slides about how passionate we are.

You do not need a spec. You do not need to know what a "stack" is or whether you want a monolith. If you knew all that, you probably would not need us. Your job on the call is to describe the problem in your own words. Our job is to ask the right questions and translate. If anyone makes you feel underprepared for not speaking fluent engineering, that is a them problem, not a you problem.

What we ask, and why

Most of the call is us asking and listening. None of it is a trick. Here is the shape of it:

  • Goals. What does success look like in six months? "We have paying customers" and "we stop losing deals to a broken signup" are very different projects. We are trying to find the actual outcome under the feature list.
  • Users. Who uses this, and what are they trying to get done? A tool five internal staff use can cut corners a public product cannot. This quietly decides half the architecture.
  • Constraints. Hard deadlines, an existing codebase, a tech your team already runs, compliance you have to meet. Constraints are not bad news. They narrow the options and make the estimate honest.
  • Budget range. Not your maximum, just a range so we do not design a thing you cannot afford. A good agency would rather know early than waste your time scoping a project that was never going to fit.
  • Timeline. When does this need to be live, and why that date? Sometimes the date is real (a funding round, a season) and sometimes it is a guess, and it helps to know which.

Notice none of those questions need a technical answer. They are about your business. The technical part is ours to figure out from your answers, and how we go about that is the same diligence we describe in how we work.

What to bring

You will get more out of the call if you show up with a few things loosely in hand. None are mandatory, and "I am not sure yet" is a perfectly good answer to any of them.

  • The problem in one or two sentences. Not the solution, the problem. "Onboarding takes our team three days of manual work per client" beats "we need a dashboard."
  • Anything that already exists. A Figma, a spreadsheet you run the business on, a repo, a competitor's product you like. Real artifacts beat descriptions every time.
  • Your rough constraints. A ballpark budget, a target date, anything that is fixed. Even fuzzy numbers help.
  • Your open questions. The things keeping you up at night. Build versus buy, whether your old code is salvageable, whether the idea is even worth building. Bring those. The honest answers are often the most valuable part of the call.

If all you have is an idea and a hunch, bring that. We have started plenty of good projects from a napkin.

What you walk away with

This is the part that separates a useful call from a pleasant chat. By the end, you should have two things.

First, a shared understanding. We should be able to say your problem back to you better than you said it to us. If we cannot, we did not listen well enough, and you have learned something useful about working with us. You should leave feeling understood, not sold to.

Second, an honest next step. Sometimes that is a proposal. Sometimes it is "you do not need us yet, go validate this with ten customers first." Sometimes it is "this is really a short consulting engagement, not a six-month build." Occasionally it is "we are not the right fit, and here is who might be." A straight answer that saves you money is worth more than a flattering one that spends it.

What you should not walk away with is pressure. No "this price is only good until Friday." No mystery about what happens next. If the call ends and you are not sure what was decided, the call failed at its one job.

A good call versus a salesy one

You can feel the difference within the first ten minutes. A good call is mostly you talking. The questions get more specific as it goes, which means they are actually listening rather than running a script. They are comfortable saying "I do not know yet, we would need to look at the code." They talk about your trade-offs, not just their capabilities. And when budget comes up, it is a frank two-way conversation, not a flinch.

A salesy call runs the other way. It is mostly them talking, usually about themselves. The questions are generic and never deepen. Everything is framed as easy, fast, and cheap, because uncomfortable truths do not close deals. There is urgency that has nothing to do with your timeline. You leave impressed and somehow no clearer about your actual problem.

The tell is simple: a good agency is trying to understand you, and a salesy one is trying to convince you. You want the first kind, and the team behind the call should be made of people who would rather lose a bad-fit project than oversell a good-fit one.

The takeaway

A discovery call is low-stakes by design. You describe a problem in plain language, we ask questions about your business, and together you figure out whether there is a project worth doing and whether we are the right people to do it. No spec required, no jargon test, no obligation at the end beyond deciding what feels right.

The barrier you are feeling is almost always bigger in your head than in the room. The worst case is a free forty-five minutes that leaves you clearer about your own problem. So if you have something you have been meaning to ask about, tell us what you are working on and we will book a call. That is the good kind of lazy: one honest conversation up front so nobody wastes months building the wrong thing.

Related service

MVP Development

A real product in users' hands in weeks, not quarters.

Learn more

Want this built right?

This is the work we do every day. Tell us what you are building and we will show you exactly how we would ship it.

hello@lazydevsagency.com